[linux-elitists] Re: undelete

Adam Lazur laz@clustermonkey.org
Wed Feb 6 21:05:39 PST 2002


Don Marti (dmarti@zgp.org) said:
> The following is an idea for a way to do undelete.
> 
> 1. Kernel level: If a system call would clobber a file, spew that
> file's meta-info, then contents out a /proc entry before doing
> the work.  System calls to intercept and check include unlink(2),
> open(2), and rename(2).
> 
> 2. Tomb daemon: Read from the /proc entry; if a file appears
> "interesting" from the meta-info, park it in a tomb area (the term
> "tomb" for this kind of area is from Purdue).  If the tomb is
> "too big", unlink the oldest files in it until it's small enough.
> (The kernel will then spew them back through the proc entry;
> ignore them.)
> 
> 3. "can I have my file back please" utilities

IMO the kernel portion isn't needed (and dumps extra crap in the
junkyard that is /proc). You could implement this stuff with a patch to
libc, LD_PRELOAD, or subterfugue. If you're going to put something like
this in the kernel, why not go all the way and implement versioning at
the filesystem level?

I talked to my amigo, Andy Korty, who works at Purdue about entombing
today. They had three flavors from what I gather: a kernel level
implementation, a libc patch, and a set of special user space commands
(replacements for rm, mv, cp, etc). The kernel patch was submitted to
FreeBSD, but they wanted a stackable filesystem version.

Anyways, in the libc version, setting ENTOMB on a per user basis
affected which files get entomed and which don't. He said it worked
pretty well, though one of the flaws was that files in the tomb are
created with time-based filenames that have a 1 second granularity.
Removing a file more than once per second caused the file already in the
tomb to get clobbered and end up in user entomb's tomb (KDE apparently
excites this).

Something like this for Linux would indeed be a nice thing to have.

-- 
Adam Lazur, Cluster Monkey



More information about the linux-elitists mailing list