Date: Mon, 18 Sep 2000 07:47:48 +0930 From: Greg Lehey <grog@lemis.com> To: Mike Meyer <mwm@mired.org> Cc: questions@freebsd.org Subject: Re: Advanced File System on FreeBSD Message-ID: <20000918074748.F67912@wantadilla.lemis.com> In-Reply-To: <14789.649.22564.273240@guru.mired.org>; from mwm@mired.org on Sun, Sep 17, 2000 at 12:42:33PM -0500 References: <121596976@toto.iv> <14789.649.22564.273240@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 17 September 2000 at 12:42:33 -0500, Mike Meyer wrote: > On Fri, 15 September 2000 at 11:37:37 +0930, Greg Lehey wrote: >> On Thursday, 14 September 2000 at 20:30:27 -0500, Jon Hamilton wrote: >>> In message <39C16654.196B0622@S1.com>, Harry Woodward-Clarke wrote: >>>> Jerry Dunham wrote: >>>>> >>>>> That "undelete" feature sure would be nice. Some of us stupid people need >>>>> it far too often. It's the one thing I REALLY liked better about the file >>>>> systems used by Microsoft and Atari. >>>> just an idea, it would be possible to 'alias' "rm" to be "mv" (it would >>>> need more than that, but that would be the gist of it), to then move the >>>> file(s) to some area which you could automagically 'clean up' via a >>>> cron-job (say once a week?) >>>> You could even write a script to do the 'rm', and pass it the parameters >>>> for 'rm', and perhaps add an extra to say "yes I really want this >>>> deleted, not just stuffed off to one side somewhere". >>> There are several problems with an approach like that, not all of which >>> are necessarily obvious at first thought. >>> >>> First, it can be problematic where you put the "deleted" files. >>> Because of namespace colissions, you need to either keep a database >>> of files -> filenames, or duplicate much of your filesystem tree, >>> which can be kind of hard on inode usage. There are also >>> ambiguities with directory permissions, if you allow the user to >>> navigate into the "deleted" tree (permissions may change on a >>> directory in the original tree, and you really should mirror those >>> changes into the "deleted" tree too). > > Actually, the "script for rm" thing has been done a number of > times. The problems you list all go away when you start thinking of it > as a *user* facility, not an OS facility. No, that's where they start. If you do it like that, there are too many ways to bypass it. For example, if you have a program which does the deletion for you. It will call unlink(2) and your directory entry is gone. >>> What happens if you have: >>> /a/b/c and /a/b/d hard linked to each other, then you delete and >>> undelete /a/b/c? You get the contents back, but lost the benefit of >>> the hard link, and when you change /a/b/d and /a/b/c doesn't change, >>> you get a nasty surprise. >> No, you'd have to remember that sort of thing. It's not difficult. > > How about this scenario. a/b/c and a/b/d are hard links. I unlink > a/b/c. I then change a/b/d without changing the inode number (a), > unlink it (b), and create a new a/b/d with a new inode number > (c). What would I get back if I undeleted a/b/c at each of the times > labeled (a), (b), and (c) - and why? You would have to have the choice. If at point (c) you decide you need the old inode, you'd need to find a way to get it. Of course, you're getting into a more general (and expensive) change management system here. >> Years ago I ran Interactive UNIX System V.3, and I installed the >> Norton Utilities for System V (yes, there was such a thing), which >> included undelete. I don't think I ever used it. I also think that >> the main thing stopping an implementation is that the people who could >> implement it don't want it. > > Actually, there is a time when the people who could implement it do > want it. That's when they are dealing with lots of newbies, and don't > want to be bothered with requests to recover accidently deleted files > from backups. I think you're looking at the "sysadmin for a large UNIX installation" scenario here. Nowadays it's more likely to be "I just deleted all my files, how do I get them back?" question, to which the hardened hacker replies "read them in from last night's backup". That's easier than writing complicated software. > Doing the script for rm solves that problem, and is much easier. Well, why don't you do it, then? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000918074748.F67912>