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  User ID  Group ID  Size  Creation time  Modification time  Access time  Deletion time  0 Link count  1 Block count  File flags [0x0] Reserved1  File acl  Directory acl  Fragment address  Fragment number  Fragment size  Direct Block #0  Direct Block #1  Direct Block #2  Direct Block #3  Direct Block #4  Direct Block #5  Direct Block #6  Direct Block #7  Direct Block #8  Direct Block #9  Direct Block #10  Direct Block #11  Indirect Block  Double Indirect Block  Triple Indirect Block 
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.