Date: Mon, 30 Oct 2006 02:22:00 -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: <004301c6fbca$33046750$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>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Meyer wrote: >> That maybe the case but does rm -f <file> remove all copies? >> Nope so its behaviour is safe even with multiple hardlinks. > > Of course it doesn't remove all copies - because there *aren't* > multiple copies. There is only *one* copy, with multiple hardlinks. > You told it to remove one hardlink, and it did that, without caring if > that's the last link or not, and erroring out because you could lose > data if it's the last link. I think you missed my point. If you had a file with multiple hardlink rm -f does NOT remove all copies it just decrements the link count. As such you will never loose data IF it was just a hardlink. This does not seem to be the case here IF it is a hardlink, it makes no difference the file is lost. This is the issue as I see it. There can be other references which the user doesnt know about. Yes thats sort of their fault but how many times have you honestly looked before doing an rm -f to see if the file in question was a hardlink? I guess none as you dont have to worry about it. The unfortunate fact here is its unexpected behaviour from a users perspective. As a user I would much prefer to have this potiential issue flagged up to me so I can make an informed decision instead the current behaviour. >> 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. > > I think it is. There's a flag that basically says "make sure no one > can read this data ever again". It does that. That said data is still > available via some other link is immaterial. No ones suggesting that it leaves it available without informing the user. >> 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. > > My personal preference is that the system do what I tell it to. If I > wanted a system that second guessed me and didn't do things that I > told it to because it thought it knew better than I did what I wanted, > I wouldn't be using Unix. So before every single rm -f you would prefer to have to check if the link count of every file was > 1 if its defined behaviour was to "destory" the file, I very much doubt that. ================================================ 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?004301c6fbca$33046750$b3db87d4>