Xref: utzoo comp.unix.questions:6850 comp.unix.wizards:8222
Path: utzoo!dciem!nrcaer!sce!graham
From: graham@sce.UUCP (Doug Graham)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Recovery ofremoved files
Message-ID: <371@sce.UUCP>
Date: 2 May 88 21:13:16 GMT
Article-I.D.: sce.371
Posted: Mon May  2 17:13:16 1988
References: <367@axis.fr> <54@lakart.UUCP> <1079@mcgill-vision.UUCP>
Organization: Systems Eng., Carleton University, Ottawa, Ontario, Canada
Lines: 38
Summary: Why zap inode?

In article <1079@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) writes:
> 
> I looked at doing this for 4.3.  Normally, people will dismiss the idea
> because 4.3 doesn't keep a freelist in the usual sense - it's more like
> bitmaps of free blocks.  But I considered leaving the block pointers
> around, just zapping the size field of the inode, so if you caught it
> before the blocks got reused (always a requirement), you could see the
> pointers still there.  However, it looks as though it isn't going to
> work.  When a file is extended, it is done by writing past the end.  If
> there is a hole, the block addresses there are left untouched as far as
> I can tell, which means they better be zero, or the file hasn't
> acquired holes; it's suddenly acquired blocks that nobody ever expected
> it to have.  Bad news.  This might be fixable, but would require a fair
> piece of kernel work (wherever the size is grown, it must be careful to
> clear block addresses as appropriate).
> 
> 					der Mouse
> 

    If this is the case, a block used to contain pointers to indirect blocks
would have to be cleared when the file was extended. Couldn't the inode
be treated similary: either when the inode is re-used, or when the
first data block is assigned to the new file, the inode is cleared.
Seems to me like a simple matter of moving a bit of code around.
The code that clears the inode when it is de-allocated, is moved
to the place where the inode is allocated.

    A co-worker and I have just finished recovering a directory full
of files that had been accidently deleted. Fortunately, he was using
a single-user SUN, so that the chances of the blocks being re-used
were slim. Since there was no useful information left in the inode,
(except the UID, why?) we could only search all of the free blocks
in the filesystem. We wrote a program that searched all of these blocks
looking for keywords that were known to exist in the files deleted.
(Doesn't work well for binary files). If the inodes had been largely
intact, a lot of time could have been saved.

Doug.