Next Contents Prev
The deletion process
Observations from looking at lots of deleted files.
Record length is adjusted to point past deleted entry
Inode Link count decreased
File blocks are returned to the free list
If Inode link count goes to zero its moved to free list
In Pre 2.0.33 kernels zero indirect blocks
It was this behavior that made it almost impossible to recover larger files.
2.2 and above most information still on disk.
Multi block directories first inode spot is zeroed.
These notes where copied out of my LDE documentation
Luckily and surprising ext2fs keeps a large amount of information on the disk after a delete. The process appears to be the following - not taken from kernel source but from looking at lots of deleted disk blocks. The ext2fs directory entry is not a fixed size it consists of five fields. These are inode, record length, name length, file type, name. Note file type only appeared later in the ext2fs directory entry and this breaks a lot of older disk editors. At first glance it may seem that record length and name length are redundant entries but this is not the case as this allows the ext2 directory entries to be deleted. Now to the delete process itself first the entry to be deleted is found. The entry size field of the entry that pointed to the deleted entry is adjusted to point the next valid entry or the end of the directory blocks so the deleted entry is simply removed from the list. This is handy for us as all we have to do is put it back into the linked list. The Inodes link count is decremented and marked as deleted if this count goes to zero and moved to the free list. Again we just need to increase the link count by 1 to show the inode is used again, we would also need to move it back to the allocated list, this I leave to fsck at this stage. Also during a delete any blocks allocated to the inode a freed so incrementing the link count on the inode will also have that Inode point to a list of possibly freed blocks. Again I have decided to let fsck sort out the mess.
Another problem I found with directories that span multi blocks is that the first inode spot is zeroed at the beginning of the block and this makes it very hard recover a file from this but I have noticed if the files where created at a similar time the inode are in sequence so the inode can check to see if it belongs.
Because it is possible have multiple hard links to a file it means that a deleted directory entry may point to a file that is was hard linked to in the past. In other words the file is not really deleted at all but just this link to it. So given this if an inode is reused there is really no way of know whether the file was allocated since the delete or if was a multi linked file.
Next Contents Prev