How a file is deleted in ufs2?

[Eric Anderson]

Rick C. Petty wrote:
> On Mon, Apr 10, 2006 at 08:20:38PM -0500, Eric Anderson wrote:
>> Hmm.. Can you explain then how a tool could recover rm'ed files (or just 
>> point me to the code snippet)?  There are a few tools that do this.  I 
>> was under the understanding that the direct/indirect/* lists got blasted 
>> away, but parts of the inode were left over.
> 
> Nope, the whole inode gets cleared.  I thought this too and discovered the
> hard way.  Maybe without softupdates, I'm not sure??
> 
> There doesn't seem to be many tools that do this, at least with UFS2.  I
> wrote my own program to try to recover a toasted drive.  My program
> searches the free blocks on the disk looking for indirect blocks (i.e.
> blocks that have certain characteristics), validates those blocks, then
> pieces together the blocks into unnamed files (file names are stored in the
> directories, not in the inode or elsewhere).  This gives you all but the
> first 12 blocks of the file, due to the on-disk structure of inodes.  It
> tries some heuristics to guess at these blocks, but the success rate is
> very low.  As long as fewer blocks have been allocated & written to the
> disk then are available on the disk, it works well (because the allocation
> algorithm is highly deterministic).
> 
> Writing the program was a major headache, and it didn't work as well as I
> was hoping.  However it did allow me to spend much time into our UFS/FFS
> code (where I did discover some potential bugs--  haven't had time to
> submit patches yet).  I started this program because ffsrecov (still)
> doesn't work with UFS2.
> 
> There is a utility (sysutils/tct) which does something similar.  It makes a
> copy of all the free blocks and tries piecing them together, using file(1)
> to verify & classify the files.  Unfortunately this tool wasn't useful to
> me.  My program instead analyzes the disk as a whole and makes
> determinations based on the block numbers (i.e. it finds indirect blocks
> which point only to freed blocks).
> 
> Inodes get scrubbed when the files are completely unlinked.  "rm -r" is
> even more invasive, as the directories which get deleted tend to have junk
> pointers to freed blocks.  The freed data blocks remain intact until the
> FFS block allocator decides to use the blocks again.  It's messy to try to
> recover deleted files.  I've learned (many times) the hard way that there's
> no substitute for periodic backups, archiving, and redundant mirroring!


Thanks!  This is great.. I appreciate all your hard work you've done, 
even if it is for nothing except for learning :).

Thanks again for the details and corrections!

Eric




-- 
------------------------------------------------------------------------
Eric Anderson        Sr. Systems Administrator        Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------