rm删除文件恢复，原作者kaihui
－－－－－by netbuddy.org kaihui。荆棘鸟 shi1110
1。在/home/songzy/test这个文件系统中任意cp一个文件，为方便我编辑了一个文本文件叫“song”，其中内容为“I LOVE IT”，使用ls -il song可看到： 17 -rw-r--r-- 1 root sys 10 Dec 01 16:13 song
2。现在使用ls -id （文件所在目录），由于song就在/home/songzy/test下，所以为ls -id /home/songzy/test: 2 /home/songzy/test
3。记住目录的I节点号，这里是2
4。umount /home/songzy/test
5。fsdb /home/songzy/test
6。到第2个i-node处，2由步骤3得到：2i 这将显示目录的inode信息。其a0，a1，a2，。。。寄存器是到数据块block的指针
7。到第一个寄存器指针指的block处： a0b
8。p128c（以字符方式显示128个bytes）： 显示目录i-node中的内容
9。a0b
10。p128e（以十进制方式显示128个bytes）： p128e 0x0000009000: 0 2 12 1 11776 0 0 2 0x0000009010: 12 2 11822 0 0 16 20 10 0x0000009020: 27759 29556 11110 28533 28260 0 0 17 0x0000009030: 448 4 29551 28263 0 0 0 0 0x0000009040: 0 0 0 0 0 0 0 0 0x0000009050: 0 0 0 0 0 0 0 0 0x0000009060: 0 0 0 0 0 0 0 0 0x0000009070: 0 0 0 0 0 0 0 0 0x0000009080: 0 0 0 0 0 0 0 0 0x0000009090: 0 0 0 0 0 0 0 0 0x00000090a0: 0 0 0 0 0 0 0 0 0x00000090b0: 0 0 0 0 0 0 0 0 0x00000090c0: 0 0 0 0 0 0 0 0 0x00000090d0: 0 0 0 0 0 0 0 0 0x00000090e0: 0 0 0 0 0 0 0 0 0x00000090f0: 0 0 0 0 0 0 0 0
11。q
12。mount /home/songzy/testnew，删除该文件：rm song
13。umount /home/songzy/testnew
14。以下进入关键部分，运行“fsdb /home/songzy/testnew”
15。到第2个i-node处，2由步骤3得到：2i
16。到第一个寄存器指针指的block处： a0b
17。p128c（以字符方式显示128个bytes）： 仔细查找显示的128个字符，寻找删除文件名。如果无法找到，需要对a1、a2等寄存器重复8、9两步，直到找到文件名。记住删除文件名开始地址和前一个文件开始地址 这里song是9034，lost+found是9020
18。a0b
19。p128e（以十进制方式显示128个bytes）： p128e 0x0000009000: 0 2 12 1 11776 0 0 2 0x0000009010: 12 2 11822 0 0 16 468 10 0x0000009020: 27759 29556 11110 28533 28260 0 0 17 0x0000009030: 448 4 29551 28263 0 0 0 0 0x0000009040: 0 0 0 0 0 0 0 0 0x0000009050: 0 0 0 0 0 0 0 0 0x0000009060: 0 0 0 0 0 0 0 0 0x0000009070: 0 0 0 0 0 0 0 0 0x0000009080: 0 0 0 0 0 0 0 0 0x0000009090: 0 0 0 0 0 0 0 0 0x00000090a0: 0 0 0 0 0 0 0 0 0x00000090b0: 0 0 0 0 0 0 0 0 0x00000090c0: 0 0 0 0 0 0 0 0 0x00000090d0: 0 0 0 0 0 0 0 0 0x00000090e0: 0 0 0 0 0 0 0 0 0x00000090f0: 0 0 0 0 0 0 0 0 根据9的结果找到两个文件相应的位置，仔细研究，我们可以发现很多有趣的东西，文件名前第一个字是文件名的长度；文件名前第三个字是文件的inode号；而文件名前第二个字是什么？？？？对比文件删除前后a0b中的值可发现它是文件是否删除的关键！因为只有删除文件前一个文件的这个值改变了！而且这个值似乎就是这个文件记录的长度，它后面一个文件删除后，它就直接跨过删除文件，所以它原来的值就是从它的I-node号到删除文件I-node号的字长度，具体到我这个例子就是20（因为e是双子表示）。那么只要恢复原来的值是否就可恢复文件？
20。恢复原来的值，注意在恢复前一定要确保“error checking on”，这可以使用“O”来切换： O 0x901c.W=20
21。17i “17”为由第19步中得到的删除文件i-node号，如果此时“a0”、“szl”等项值非零，那表示文件还可恢复，否则就放弃吧（因为即使恢复，内容也已没有，我不清楚为什么有时刚删除的文件就恢复不出）。
22。17i.ln=1
23。q
24。fsck /home/songzy/test Bad Inode Map; SALVAGE? y ** Phase 5b - Salvage Inode Map ** Phase 6 - Check Block Map Bad Block Map; SALVAGE? y ** Phase 6b - Salvage Block Map 9 files 352 blocks 7840 free ***** Filesystem was modified ***** 运行“fsck”会检查文件系统的一致性，自动修复文件的inode map、block map，均选择“y”
25。mount /home/songzy/test
26。ls -l可以看到文件已经恢复。
如果你需要转贴这篇文章请写明原作者kaihui（我有幸1年前和他一起做的试验）
－－－ kaihui。荆棘鸟 shi1110
谢谢
1。在/home/songzy/test这个文件系统中任意cp一个文件，为方便我编辑了一个文本文件叫“song”，其中内容为“I LOVE IT”，使用ls -il song可看到： 17 -rw-r--r-- 1 root sys 10 Dec 01 16:13 song
2。现在使用ls -id （文件所在目录），由于song就在/home/songzy/test下，所以为ls -id /home/songzy/test: 2 /home/songzy/test
3。记住目录的I节点号，这里是2
4。umount /home/songzy/test
5。fsdb /home/songzy/test
6。到第2个i-node处，2由步骤3得到：2i 这将显示目录的inode信息。其a0，a1，a2，。。。寄存器是到数据块block的指针
7。到第一个寄存器指针指的block处： a0b
8。p128c（以字符方式显示128个bytes）： 显示目录i-node中的内容
9。a0b
10。p128e（以十进制方式显示128个bytes）： p128e 0x0000009000: 0 2 12 1 11776 0 0 2 0x0000009010: 12 2 11822 0 0 16 20 10 0x0000009020: 27759 29556 11110 28533 28260 0 0 17 0x0000009030: 448 4 29551 28263 0 0 0 0 0x0000009040: 0 0 0 0 0 0 0 0 0x0000009050: 0 0 0 0 0 0 0 0 0x0000009060: 0 0 0 0 0 0 0 0 0x0000009070: 0 0 0 0 0 0 0 0 0x0000009080: 0 0 0 0 0 0 0 0 0x0000009090: 0 0 0 0 0 0 0 0 0x00000090a0: 0 0 0 0 0 0 0 0 0x00000090b0: 0 0 0 0 0 0 0 0 0x00000090c0: 0 0 0 0 0 0 0 0 0x00000090d0: 0 0 0 0 0 0 0 0 0x00000090e0: 0 0 0 0 0 0 0 0 0x00000090f0: 0 0 0 0 0 0 0 0
11。q
12。mount /home/songzy/testnew，删除该文件：rm song
13。umount /home/songzy/testnew
14。以下进入关键部分，运行“fsdb /home/songzy/testnew”
15。到第2个i-node处，2由步骤3得到：2i
16。到第一个寄存器指针指的block处： a0b
17。p128c（以字符方式显示128个bytes）： 仔细查找显示的128个字符，寻找删除文件名。如果无法找到，需要对a1、a2等寄存器重复8、9两步，直到找到文件名。记住删除文件名开始地址和前一个文件开始地址 这里song是9034，lost+found是9020
18。a0b
19。p128e（以十进制方式显示128个bytes）： p128e 0x0000009000: 0 2 12 1 11776 0 0 2 0x0000009010: 12 2 11822 0 0 16 468 10 0x0000009020: 27759 29556 11110 28533 28260 0 0 17 0x0000009030: 448 4 29551 28263 0 0 0 0 0x0000009040: 0 0 0 0 0 0 0 0 0x0000009050: 0 0 0 0 0 0 0 0 0x0000009060: 0 0 0 0 0 0 0 0 0x0000009070: 0 0 0 0 0 0 0 0 0x0000009080: 0 0 0 0 0 0 0 0 0x0000009090: 0 0 0 0 0 0 0 0 0x00000090a0: 0 0 0 0 0 0 0 0 0x00000090b0: 0 0 0 0 0 0 0 0 0x00000090c0: 0 0 0 0 0 0 0 0 0x00000090d0: 0 0 0 0 0 0 0 0 0x00000090e0: 0 0 0 0 0 0 0 0 0x00000090f0: 0 0 0 0 0 0 0 0 根据9的结果找到两个文件相应的位置，仔细研究，我们可以发现很多有趣的东西，文件名前第一个字是文件名的长度；文件名前第三个字是文件的inode号；而文件名前第二个字是什么？？？？对比文件删除前后a0b中的值可发现它是文件是否删除的关键！因为只有删除文件前一个文件的这个值改变了！而且这个值似乎就是这个文件记录的长度，它后面一个文件删除后，它就直接跨过删除文件，所以它原来的值就是从它的I-node号到删除文件I-node号的字长度，具体到我这个例子就是20（因为e是双子表示）。那么只要恢复原来的值是否就可恢复文件？
20。恢复原来的值，注意在恢复前一定要确保“error checking on”，这可以使用“O”来切换： O 0x901c.W=20
21。17i “17”为由第19步中得到的删除文件i-node号，如果此时“a0”、“szl”等项值非零，那表示文件还可恢复，否则就放弃吧（因为即使恢复，内容也已没有，我不清楚为什么有时刚删除的文件就恢复不出）。
22。17i.ln=1
23。q
24。fsck /home/songzy/test Bad Inode Map; SALVAGE? y ** Phase 5b - Salvage Inode Map ** Phase 6 - Check Block Map Bad Block Map; SALVAGE? y ** Phase 6b - Salvage Block Map 9 files 352 blocks 7840 free ***** Filesystem was modified ***** 运行“fsck”会检查文件系统的一致性，自动修复文件的inode map、block map，均选择“y”
25。mount /home/songzy/test
26。ls -l可以看到文件已经恢复。
如果你需要转贴这篇文章请写明原作者kaihui（我有幸1年前和他一起做的试验）
－－－ kaihui。荆棘鸟 shi1110
谢谢
浙公网安备 33010602011771号