Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Oct 2006 02:43:58 +0100
From:      Joerg Pernfuss <elessar@bsdforen.de>
To:        <freebsd-hackers@freebsd.org>
Subject:   Re: [patch] rm can have undesired side-effects
Message-ID:  <20061030024358.39a12359@loki.starkstrom.lan>
In-Reply-To: <00f201c6fbb6$0c6bd150$b3db87d4@multiplay.co.uk>
References:  <20061029222847.GA68272@marvin.astase.com> <20061030003628.42bc5f8d@loki.starkstrom.lan> <00f201c6fbb6$0c6bd150$b3db87d4@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_72hEnRl=0BuVy3QGkiY+3eW
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sun, 29 Oct 2006 23:57:45 -0000
"Steven Hartland" <killing@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.
>=20
> 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.
=20
> 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
--=20
| /"\   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.    |

--Sig_72hEnRl=0BuVy3QGkiY+3eW
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)

iD8DBQFFRVjeH31s/bvKrSQRAtHgAJ9rBMUnz5YfyZQZgTh/2PnkSI8D0QCaAxvy
t7L5/tdZ5ley+qsavqqtXog=
=yVEr
-----END PGP SIGNATURE-----

--Sig_72hEnRl=0BuVy3QGkiY+3eW--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061030024358.39a12359>