Next Previous Contents

## 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