[patch] rm can have undesired side-effects

[Joerg Pernfuss]

On Sun, 29 Oct 2006 23:57:45 -0000
"Steven Hartland" <killing at multiplay.co.uk> wrote:

> That maybe the case but does rm -f <file> remove all copies?
> Nope so its behaviour is safe even with multiple hardlinks.
> 
> From the description I've seen thats not the case for -P
> here and as such I dont think its quite a simple as that.

The problem is that -P is the only option that actually modifies
data instead of just the filesystem. From the online man pages
it was added somewhere between 4.3BSD and 4.4BSD Lite2, so the
FreeBSD CVS doesn't cover the initial -P commit. The option also
does not seem to be POSIX or sth similar, but a historic BSD thing.
 
> My personal preference would be for it to warn or perhaps
> error if the link count is not zero. Possibly use -f to
> override this but even that I'd say is dangerous.

s/not zero/greater than one/

BSD behaviour:
- OpenBSD handles hardlinks since 3.3:
     -P      Overwrite regular files before deleting them.  Files
	     are overwritten three times, first with the byte pattern
	     0xff, then 0x00, and then 0xff again, before they are
	     deleted.  Files with multiple links will not be overwritten.
- NetBSD uses 0xff, 0x00 and then random data. Ignores link count
- DragonFlyBSD has the same behaviour as FreeBSD

External behaviour:
- bcwipe ignores the link count
- GNU's shred ignores the link count too (`shred $file' as well as
  `shred -u $file')

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 :)

That would mean that `rm -P <file>' with <file> having a link count of
at least 2, would behave like `rm <file>' (and like Romain suggested).

	Joerg
-- 
| /"\   ASCII ribbon   |  GnuPG Key ID | e86d b753 3deb e749 6c3a |
| \ / campaign against |    0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 |
|  X    HTML in email  |        .the next sentence is true.       |
| / \     and news     |     .the previous sentence was a lie.    |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20061030/1700ccf5/signature.pgp