From owner-freebsd-questions Sat Sep 16 18:56:19 2000 Delivered-To: freebsd-questions@freebsd.org Received: from rider.dunham.org (rider.dunham.org [207.170.123.194]) by hub.freebsd.org (Postfix) with ESMTP id EA9BC37B42C for ; Sat, 16 Sep 2000 18:56:13 -0700 (PDT) Received: (from dunham@localhost) by rider.dunham.org (8.8.8/8.7.3) id UAA28161; Sat, 16 Sep 2000 20:54:35 -0500 (CDT) Message-ID: <20000916205434.D27592@rider.dunham.org> Date: Sat, 16 Sep 2000 20:54:34 -0500 From: Jerry Dunham To: Greg Lehey Cc: Harry Woodward-Clarke , freebsd-questions@freebsd.org, Jon Hamilton Subject: Re: Advanced File System on FreeBSD References: <39C16654.196B0622@S1.com> <20000915013028.04F061EF@woodstock.monkey.net> <20000915113737.M71517@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <20000915113737.M71517@wantadilla.lemis.com>; from Greg Lehey on Fri, Sep 15, 2000 at 11:37:37AM +0930 X-Operating-System: FreeBSD rider.dunham.org 2.2.6-RELEASE Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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). > > 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. I know nothing about how the file system works, yet that makes amazingly good sense to me. > > 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. At least the sysadmin would have the option to enable or not. Makes sense to me. > > 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. That's typical. And those of us stupid enough to really need it aren't smart enough to implement it. That probably means it'll never happen. -- Jerry Dunham FreeBSD (512)335-0674 (H) jdunham@fc.net jerry@dunham.org Lottery: A tax on people who are really bad at math To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message