Date: Fri, 15 Sep 2000 11:37:37 +0930 From: Greg Lehey <grog@lemis.com> To: Jon Hamilton <hamilton@pobox.com> Cc: Harry Woodward-Clarke <Harry.Woodward-Clarke@S1.com>, Jerry Dunham <jdunham@fc.net>, freebsd-questions@FreeBSD.ORG Subject: Re: Advanced File System on FreeBSD Message-ID: <20000915113737.M71517@wantadilla.lemis.com> In-Reply-To: <20000915013028.04F061EF@woodstock.monkey.net>; from hamilton@pobox.com on Thu, Sep 14, 2000 at 08:30:27PM -0500 References: <39C16654.196B0622@S1.com> <20000915013028.04F061EF@woodstock.monkey.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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). There are alternatives. You could find the "wastebasked" just like the way you find the root directory of the file system (which doesn't have a name until you mount it somewhere). The root is always inode 2, at least on all UNIX and BSD systems; it's possible Linux does this differently, though the Linux system to which I have access appears to do the same as UNIX. My recollection is that inodes 0 and 1 are magic, but I don't recall which kind of magic. But we could make inode 3 magic as well, and make it the wastebasket. I'm sure it would be possible to maintain a list of deleted files, their sizes and some tuning information (how much do you want to keep, when do you remove stuff even if you haven't fulfilled your quota, etc.) in this hidden area. > 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 do you deal with users who have disk quotas? When they delete that > giant email spam they got and it continues to suck up their quota in > a "helpful" deletion area, they become unhappy. That's a better question. One approach would be to allow individual users to decide whether they want to use the undelete facility or not. > Yet another problem with that approach is that it only addresses > files which get removed with "rm", and not files which are removed > via programs using unlink(2) which would include most file browsers, > etc. Not the way I would do it. This should be a kernel-level function. > If you're going to do this kind of thing, you really need support for > it directly in the filesystem, and even then it can be dicey. Correct. But it's not that difficult. 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. Greg -- When replying to this message, please copy the original recipients. 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?20000915113737.M71517>