Re: ext3 and undeletion

[Andreas Dilger <adilger@turbolabs.com>]

On Feb 25, 2002  10:40 -0800, Mike Fedyk wrote:
> On Mon, Feb 25, 2002 at 01:08:23PM -0500, Richard B. Johnson wrote:
> > > Rather than implementing this in the filesystem itself, I'd first try
> > > writing a libc shim that overrides unlink(). You could copy files to
> > > safety, or do anything else you want, before they actually get deleted...
> >
> > Yes... unlink() becomes `mv /path/filename /deleted/path/filename`
> > Simple.  For idiot users, you can just make such an alias for those
> 
> It would be nice if there was a 'deleted' dir per mount point, as that would
> keep similar speeds as rm.  Also, 'deleted' would probably have to be marked
> writable, but not readable and would need a suid binary to read that dir and
> limit the output to only list files owned by the calling uid.  But that's a
> bit too offtopic for this list...

Yes, the deleted (prefer /.deleted or similar) directory would _have_ to
be per mount point for a few reasons:
1) speed - copying all deleted files across mountpoints would be _slow_.
2) space - you would have to have a _huge_ root directory otherwise.
3) locality - need to handle network filesystems properly (e.g. being able
              to undelete a file on a network fs if it was deleted on a
	      different host).

While I've seen this "change unlink in libc" suggestion many, many times
I don't think I've ever seen it implemented.  Is it just because the people
who can do it don't want to, and by the time the people who want it can
implement it they don't want it anymore?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/