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.