从表面上看，这种方法要容易得多。然而，正如上面提到的，它目前还无法处理超过 12 个块的文件。
对于您要恢复的每个 inode，您必须将使用计数设置为 1，并将删除时间设置为零。这可以通过 debugfs 中的 mi（修改 inode）命令来完成。以下是一些示例输出，修改上面提到的 inode 148003
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]
也就是说，我将删除时间设置为 0，将链接计数设置为 1，然后对于其他每个字段都直接按了回车键。诚然，如果您要恢复大量文件，这会有点笨拙，但我认为您可以应付。如果您想要的是 chrome，您就会使用带有漂亮的“回收站”的图形化“操作系统”了。
顺便说一句：mi 输出中提到了 inode 中的“创建时间”字段。这是一个谎言！（或者至少是误导性的。）事实是，在 UNIX 文件系统中，您无法判断文件何时创建。struct stat 的 st_ctime 成员指的是“inode 更改时间”，即上次任何 inode 详细信息被更改的时间。今天的课程到此结束。
请注意，比我使用的版本更新的 debugfs 版本可能不包括上面列表中的某些字段（特别是 Reserved1 和（一些？）片段字段）。
一旦您修改了 inode，您就可以退出 debugfs 并输入
# e2fsck -f /dev/hda5
其思路是，每个已删除的文件都已被字面上地取消删除，但它们都没有出现在任何目录项中。e2fsck 程序可以检测到这一点，并将为文件系统 /lost+found 目录中的每个文件添加一个目录项。（因此，如果分区通常挂载在 /usr 上，则文件将在您下次挂载时出现在 /usr/lost+found 中。）所有剩下的工作就是从每个文件的内容中找出其名称，并将其返回到文件系统树中的正确位置。
当您运行 e2fsck 时，您将获得一些信息性输出，以及一些关于修复哪些损坏的问题。对于任何提及“摘要信息”或您已更改的 inode 的问题，请回答“yes”。其他任何事情都由您决定，尽管通常最好对所有问题都回答“yes”。当 e2fsck 完成后，您可以重新挂载文件系统。
实际上，除了让 e2fsck 将文件留在 /lost+found 中之外，还有另一种选择：您可以使用 debugfs 在文件系统中创建一个指向 inode 的链接。在您修改 inode 后，在 debugfs 中使用 link 命令
debugfs: link <148003> foo.txt
这将在 debugfs 认为的当前目录中创建一个名为 foo.txt 的文件；foo.txt 将是您的文件。您仍然需要运行 e2fsck 来修复摘要信息和块计数等等。