Date: Thu, 14 Sep 2000 20:30:27 -0500 From: Jon Hamilton <hamilton@pobox.com> To: Harry Woodward-Clarke <Harry.Woodward-Clarke@S1.com> Cc: Jerry Dunham <jdunham@fc.net>, freebsd-questions@FreeBSD.ORG Subject: Re: Advanced File System on FreeBSD Message-ID: <20000915013028.04F061EF@woodstock.monkey.net> In-Reply-To: Your message of "Fri, 15 Sep 2000 10:59:16 %2B1100." <39C16654.196B0622@S1.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <39C16654.196B0622@S1.com>, Harry Woodward-Clarke wrote: } Hiya, } > } > 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). 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. 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. 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. 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. -- Jon Hamilton hamilton@pobox.com 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?20000915013028.04F061EF>