11. Modifying inodes directly
This method is, on the surface, much easier. However, as mentioned above, it cannot yet cope with files longer than 12 blocks.
For each inode you want to recover, you must set the usage count to one, and
set the deletion time to zero. This is done with the mi (modify inode)
command in debugfs. Some sample output, modifying inode 148003 from
above:
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
That is, I set the deletion time to 0 and the link count to 1 and just pressed return for each of the other fields. Granted, this is a little unwieldy if you have a lot of files to recover, but I think you can cope. If you'd wanted chrome, you'd have used a graphical `operating system' with a pretty `Recycle Bin'.
By the way: the mi output refers to a `Creation time' field in the
inode. This is a lie! (Or misleading, anyway.) The fact of the matter is
that you cannot tell on a UNIX file system when a file was created. The
st_ctime member of a struct stat refers to the `inode change time',
that is, the last time when any inode details were changed. Here endeth
today's lesson.
Note that more recent versions of debugfs than the one I'm using probably
do not include some of the fields in the listing above (specifically,
Reserved1 and (some of?) the fragment fields).
Once you've modified the inodes, you can quit debugfs and say:
# e2fsck -f /dev/hda5
The idea is that each of the deleted files has been literally undeleted, but
none of them appear in any directory entries. The e2fsck program can
detect this, and will add a directory entry for each file in the
/lost+found directory of the file system. (So if the partition is
normally mounted on /usr, the files will now appear in
/usr/lost+found when you next mount it.) All that still remains to
be done is to work out the name of each file from its contents, and return
it to its correct place in the file system tree.
When you run e2fsck, you will get some informative output, and some
questions about what damage to repair. Answer `yes' to everything that refers
to `summary information' or to the inodes you've changed. Anything else I
leave up to you, although it's usually a good idea to say `yes' to all the
questions. When e2fsck finishes, you can remount the file system.
Actually, there's an alternative to having e2fsck leave the files in
/lost+found: you can use debugfs to create a link in the
file system to the inode. Use the link command in debugfs after
you've modified the inode:
debugfs: link <148003> foo.txt
This creates a file called foo.txt in what debugfs thinks is the
current directory; foo.txt will be your file. You'll still need to run
e2fsck to fix the summary information and block counts and so on.
Next Previous Contents