What happens during an unlink(2)

[Dave Martindale]

In article <442 at hropus.UUCP> jgy at hropus.UUCP (jgy) writes:
>Someone said:
>> When you unlink a file, the disk block addresses in the inode are
>> zeroed, not the actual data blocks. Zeroing the inode is tantamount to
>> 'forgetting' where the data is actually stored. ..............
>
>This is not true, all that is necessary is that the blocks be put on the
>freelist, the inode marked unallocated and added to the inode freelist.
>If this were the case you could just go and look at your unallocated inode
>for the block information. The onus would be on the system to clear the
>inode before being reused. The only possible dispute I can see with this
>is (problems with a crash can be handled) that of who should be
>"charged" with clearing of someone else's dirty inode!

There is still a way of getting back most of the data of a just-deleted
file on an inactive filesystem: the data blocks have just been put onto
the freelist, and 99/100 of them still have their original data in them.
Just poke through the first blocks of the free list to get your data.

If someone has already allocated the blocks to a new file (by writing on
them), tough luck.  This generally will happen within a few seconds, so
there seems little point in writing out inodes with the block pointers
still intact - it will seldom do you much good.

But you have to modify the inode on disk anyway, to make sure it is marked
free in case a crash happens, and if you're going to modify even one bit
of it you might as well zero the whole thing - the cost is primarily
in the disk I/O and copying.