Date: Sun, 17 Sep 2000 12:42:33 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: questions@freebsd.org Cc: grog@lemis.com Subject: Re: Advanced File System on FreeBSD Message-ID: <14789.649.22564.273240@guru.mired.org> In-Reply-To: <121596976@toto.iv>
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). 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. It runs as the user, and only saves files under the users $HOME. Files get moved to $HOME/.wastebasket (or some such) as the user, and .wastebasket is mode 700. While these restrictions are pretty severe, the average non-sysadmin will seldom notices them. > 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 >[...] > > 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? > 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. Doing the script for rm solves that problem, and is much easier. <mike 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?14789.649.22564.273240>