Skip site navigation (1)Skip section navigation (2)
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>