On Sun, 29 Oct 2006 23:57:45 -0000 "Steven Hartland" <[EMAIL PROTECTED]> 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. |
signature.asc
Description: PGP signature
