[linux-elitists] undelete

Dan Wilder dan@ssc.com
Tue Feb 5 19:00:40 PST 2002


On Tue, Feb 05, 2002 at 06:33:28PM -0800, Don Marti wrote:
> (Asking how to do file undelete is of course highly non-elitist,
> since the true elitist thing to do is come up with a good reason
> why you didn't need the file, and _meant_ to clobber it.)
> 
> 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
> 
> -- 
> Don Marti                                          
> http://zgp.org/~dmarti       Join the Distributed Unisys Google Experiment.
> dmarti@zgp.org                 <a href="http://burnallgifs.org/">Unisys</a>
> KG6INA                                                          everywhere. 
> _______________________________________________
> linux-elitists 
> http://zgp.org/mailman/listinfo/linux-elitists
> 

man recover

on a debian system describes one such.  Sorta.  

Inodes don't get recycled right away after they're freed,
so deleted files have a sort of ghostly existance.  

"recover" asks for natural history information then
picks through the free inode list looking for ones that
match.  Then it attaches them to files named (here's where 
it isn't a full undelete) after the inode.  

What's missing is some prioritization which best serves
local undelete needs, in the recycling of inodes, and a way 
to recover names by which inodes were once referenced.

http://recover.sourceforge.net/linux/recover/

-- 
-----------------------------------------------------------------
 Dan Wilder <dan@ssc.com>   Technical Manager & Editor
 SSC, Inc. P.O. Box 55549   Phone:  206-782-8808
 Seattle, WA  98155-0549    URL http://www.linuxjournal.com/
-----------------------------------------------------------------



More information about the linux-elitists mailing list