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/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:17 EST