Newsgroups: comp.unix.wizards
Path: utzoo!utgpu!jarvis.csri.toronto.edu!neat.ai.toronto.edu!rayan
From: rayan@ai.toronto.edu (Rayan Zachariassen)
Subject: minimal loss of information when deallocating inodes?
Message-ID: <88Dec24.170417est.38019@neat.ai.toronto.edu>
Summary: why stomp on inode information?
Date: Sat, 24 Dec 88 17:04:12 EST

One of the filesystems on an ``unsupported'' machine lost all user files by
(the equivalent of) rm -r done automatically by a script late at night.
There was no other activity on the filesystem since the disaster, so I
made an image copy and wrote a little program to fish out the textual data
in the filesystem.  So, I think, "hey, if all the inodes are still there
they might have links to the data blocks of each file".  Dragging out my
inode-list walker routine, it turns out that all deallocated inodes have
null mode, size, nlink, and db[] fields.  The latter is the real killer,
since without the disk block information, the old inode is useless.  Knowing
the size would be pretty helpful too, depending on the contents of db[].

I'd think that a zero nlink field should be enough to mark the inode as
deallocated.  I can imagine robustness (i.e. paranoid) reasons for zeroing
out the other fields, but is it *really* necessary?  If they aren't zeroed
out, the information can be used to reconstruct removed files as long as the
various blocks haven't been stomped on.

Comments?

I dimly recall some discussion about this a long time ago, does anyone
remember the answers/conclusions?

rayan