[patch] rm can have undesired side-effects

[Matthew Dillon]

::...
::Although I am a big defender of "the user should know what he does",
::the "right thing to do"[TM] would probably be to sync the behaviour
::of FreeBSD's rm(1) to OpenBSD and lobby NetBSD and DragonFlyBSD to do
::the same :)
::
::	Joerg
:
:    I agree.  I will make this change in DragonFly right now, in fact.
:    The -P option really needs to be consistent across environments
:    and my take on the original design was so users could alias rm to
:    rm -P in their .cshrc files.  Clearly it cannot destroy the contents
:    of the file in the presence of hard links when used in that context.
:
:					-Matt

    Followup note here.  OpenBSD's /bin/rm source is doing something
    unexpected... it isn't unlink()ing the file if it has > 1 hardlinks
    and -P is used.  That is its current behavior.

    pkgbox# /usr/obj/archive/OpenBSD-current/src/bin/rm/rm -P /tmp/x
    pkgbox# echo "x" > /tmp/x
    pkgbox# ln /tmp/x /tmp/y
    pkgbox# /usr/obj/archive/OpenBSD-current/src/bin/rm/rm -P /tmp/x
    rm: /tmp/x (inode 36): not overwritten due to multiple links
    pkgbox# ls -la /tmp/x /tmp/y
    -rw-r--r--  2 root  wheel  2 Nov  4 18:19 /tmp/x
    -rw-r--r--  2 root  wheel  2 Nov  4 18:19 /tmp/y
    pkgbox# 

    I'm not sure I agree with this.  It makes -P unusable as a .cshrc alias.
    I would have expected it to still unlink the file.

    In anycase, for now I am going to sync DragonFly's rm with OpenBSD anyhow,
    even though I'm scratching my head a bit.  This may be just as broken
    as before, just in a different (and safer) way.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>