☰

为什么 debugfs 中的 lsdel 不起作用？

tag-icon • tag-icon data-recovery debugfs
为什么 debugfs 中的 lsdel 不起作用？

我的分区/dev/sdb1的文件系统ext3安装在 /mnt/folder.

我触摸一个文件/mnt/folder并删除该文件。然后我使用debugfs /dev/sdb1然后输入lsdel，但它说“发现 0 个已删除的索引节点。”

什么是问题？我如何恢复我的文件调试文件？

答案1

不适合 ext3/ext4。

从男人:

list_deleted_inodes [限制]
    列出已删除的索引节点，可选择限制为以下范围内删除的索引节点限制
    几秒钟前。也可用作伊斯德尔。

    此命令对于从意外文件删除中恢复很有用
    对于 ext2 文件系统。不幸的是，它对于这个目的没有用处。
    如果使用 ext3 或 ext4 删除文件，因为 inode 的
    inode 释放后，数据块不再可用。

例子：

$ echo Hello > foo.txt
$ ls -ial
35692596 .
35692545 ..
35692597 foo.txt

$ sudo debugfs -R 'inode_dump <35692597>' /dev/sdc5

0000  b481 e803 0600 0000 82d0 d056 82d0 d056  ...........V...V
0020  82d0 d056 0000 0000 e803 0100 0800 0000  ...V............
0040  0000 0000 0100 0000 d36c 2f0b 0000 0000  .........l/.....
0060  0000 0000 0000 0000 0000 0000 0000 0000  ................
*
...

由于这是一个小文件，我们只有一个块i_块（偏移量0x28）。

上式可以整理为：

b481      |      81b4 = i_mode        : 0100664 (octal)
e803      |      03e8 = i_uid         :    1000
0600 0000 | 0000 0006 = i_size_lo     :       6
dbd7 d056 | 56d0 d7db = i_atime       : Fri Feb 26 23:55:23 CET 2016
dbd7 d056 | 56d0 d7db = i_ctime       : Fri Feb 26 23:55:23 CET 2016
dbd7 d056 | 56d0 d7db = i_mtime       : Fri Feb 26 23:55:23 CET 2016
0000 0000 | 0000 0000 = i_dtime       :       0
e803      |      03e8 = i_gid         :    1000
0100      |      0001 = i_links_count :       1
0800 0000 | 0000 0008 = i_blocks_lo   :       8, 8 * 512 = 4096 b
0000 0000 | 0000 0000 = i_flags       :       0
0100 0000 | 0000 0001 = i_osd1        :       1

Direct Block Address:

d36c 2f0b | 0b2f 6cd3 = i_block[0]    : 187657427
0000 0000 | 0000 0000 = ... no more

我们可以按块大小（此处为 4096）计算分区中数据的偏移量：

0x0b2f6cd3 * 4096 = 768644820992

然后通过直接读取转储：

$ sudo dd if=/dev/sdc5 bs=1 skip=768644820992 count=6 | hd
00000000  48 65 6c 6c 6f 0a                                 |Hello.|

现在，如果我们rm foo.txt，一个能dd通过与上面相同的命令获取数据。但它随时可以被覆盖。

但如果我们不知道这个偏移量，我们就会做空。

$ ls -ai1
35692596 .
35692545 ..

$ sudo debugfs -R 'ls -d <35692596>' /dev/sdc5
 35692596  (12) .    35692545  (4084) ..   <35692597> (4072) foo.txt

$ sudo debugfs -R 'inode_dump <35692597>' /dev/sdc5

现在的索引节点数据是：

b481      | 
e803      |
0000 0000 | 0000 0000 = i_size_o      : 0                            *changed
dbd7 d056 | 56d0 d7db = i_atime       : Fri Feb 26 23:55:23 CET 2016
e5d7 d056 | 56d0 d7e5 = i_ctime       : Fri Feb 26 23:55:33 CET 2016 *changed
e5d7 d056 | 56d0 d7e5 = i_mtime       : Fri Feb 26 23:55:33 CET 2016 *changed
e5d7 d056 | 56d0 d7e5 = i_dtime       : Fri Feb 26 23:55:33 CET 2016 *changed
e803      |
0000      |      0000 = i_links_count : 0                            *changed
0000 0000 | 0000 0000 = i_blocks_lo   : 0                            *changed
0000 0000 |
0100 0000 |

0000 0000 | 0000 0000 = i_block[0]    : Zeroed out.                  *changed
0000 0000 |
0000 0000 |

如您所见，块数据已清零。

答案2

调试是不是文件恢复程序。如果你很幸运的话，它有时可以恢复已删除的文件，这是一个意外。

实际操作系统（例如，与 MS-DOS 相对）中的文件恢复拼写为“备份”。

相关内容