Date: Mon, 30 Oct 2006 03:30:22 -0000 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Mike Meyer" <mwm@mired.org> Cc: Joerg Pernfuss <elessar@bsdforen.de>, freebsd-hackers@freebsd.org Subject: Re: [patch] rm can have undesired side-effects Message-ID: <008d01c6fbd3$bfd29cc0$b3db87d4@multiplay.co.uk> References: <20061029222847.GA68272@marvin.astase.com><20061030003628.42bc5f8d@loki.starkstrom.lan><00f201c6fbb6$0c6bd150$b3db87d4@multiplay.co.uk><17733.22173.12972.677850@bhuda.mired.org><004301c6fbca$33046750$b3db87d4@multiplay.co.uk> <17733.27312.946128.816900@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Mike Meyer" <mwm@mired.org>
> Actually, rm -f either removes no copies or removes them all, because
> there's only one copy. It either gets removed (if this was the last
> link) or it doesn't. And you seem to have missed my point. Having a
> "destroy this data" option that doesn't do it based on the link count
> makes as much sense as having "rm" not remove a link based on the link
> count.
Hehe your saying that removing a file doesnt always remove the
file, thanks for making my point :D
Its clear in my mind and others it seems, that the OpenBSD method
is how this should work.
You can procrastinate all you like about "designed for adults"
that doesnt change the fact destroying the data in a file referenced
else where is not what the user would expect, adult or not.
Just like they wouldn't expect rm -f to automatically decrement
the reference count to 0 and erase the file from FS totally. This
would be the case by your argument, as reading the man page of rm
there is no mention of anything like:
"Only if the reference count reaches 0 is the file really removed
from the file system."
It only stats the following:
"The rm utility exits 0 if all of the named files or file hierarchies
were removed"
But as we all know the files may be referenced else where and hence
said files may not in fact be "removed" at all only their local
reference.
So either the docs need to be updated to make it VERY clear this
unexpected behaviour will occur or the code and the docs updated
to make it function in a more predictable manor.
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008d01c6fbd3$bfd29cc0$b3db87d4>