Date: Sat, 16 Sep 2000 20:54:34 -0500 From: Jerry Dunham <dunham@dunham.org> To: Greg Lehey <grog@lemis.com> Cc: Harry Woodward-Clarke <Harry.Woodward-Clarke@S1.com>, freebsd-questions@freebsd.org, Jon Hamilton <hamilton@pobox.com> Subject: Re: Advanced File System on FreeBSD Message-ID: <20000916205434.D27592@rider.dunham.org> In-Reply-To: <20000915113737.M71517@wantadilla.lemis.com>; from Greg Lehey on Fri, Sep 15, 2000 at 11:37:37AM %2B0930 References: <39C16654.196B0622@S1.com> <20000915013028.04F061EF@woodstock.monkey.net> <20000915113737.M71517@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000916205434.D27592>