Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!decwrl!ucbvax!mindcrf.UUCP!karish
From: karish@mindcrf.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Re.: UNdeleting files
Message-ID: <9008072259.AA18418@mindcrf.mindcraft.com>
Date: 7 Aug 90 22:59:06 GMT
References: <6959@helios.TAMU.EDU> <14020108@hpisod2.HP.COM> <1990Aug7.153118.28729@maths.tcd.ie>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Mindcraft, Inc.
Lines: 30

In article <1990Aug7.153118.28729@maths.tcd.ie> chogan@maths.tcd.ie
(Christine Hogan) writes:
>A similar thing has just happened here, and we don't have fsdb either.
>The machine has been untouched since the directory was deleted.
>Any suggestions ?

    Whether done with fsdb or not, the task is to read the disk
    partition block by block, check each block to determine whether
    it's part of the data to be recovered, and reassemble the recovered
    blocks.

    You have to be able to recognize the blocks you want, and weed out
    obsolete versions that may be on the partition.  Much easier for
    text files than for pieces of executables or binary data files.

    I'd write a filter to open the raw device, read out blocks and try
    to guess whether they're text, and feed the text blocks, one by
    one, to grep.  Then spit out the block number for each match.

    If you can duplicate the functionality of fsdb to the extent of
    finding the inodes of the deleted files, you may be able to save a
    lot of trouble.  Unfortunately, there'll still be some trial and
    error involved, because the act of deleting a file involves
    deleting the inode number from the directory entry where it had
    been associated with a file name (and, on some systems, removing
    the entire directory entry).
-- 

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000