迅维网

标题: WINHEX修复“文件或目录损坏且无法读取” [打印本页]

作者: 北京令狐冲 时间: 2010-4-24 00:13
标题: WINHEX修复“文件或目录损坏且无法读取”
本帖最后由北京令狐冲于 2010-4-24 00:16 编辑

原创案例，谢绝转载

远程做的一个“文件或目录损坏且无法读取”的恢复。232G的NTFS分区D，XP系统，每簇扇区数8，用winhex无法读取分区，提示错误，通过物理磁盘访问该分区，根目录下看不到任何文件，检查DBR，没有发现明显的异常。
PS：由于是远程恢复，原盘未做截图，本教程是模拟了原始分区数据丢失时的情景，请参考恢复思路，如有不足，请各位指正！

跳转到第分区E的EBR（虚拟MBR）位置的上一个扇区，找到损坏的分区的备份的DBR，通过winhex提供的计算hash功能，计算哈希值。再与第一个DBR的hash值对比。完全一样。（也可以通过winhex提供的同步和对比功能进行验证，winhex会不同的字节上显示黑色）
跳转到$MFT的开始位置，也即是$MFT自身的记录。发现其起始特征本应该是ASCII码的“FILE”四个字节，现在变成了ASCII码“BAD？”。这是造成提示“文件或目录损坏且无法读取”的关键问题所在。
跳转到偏移512=242位置，也就是这个MFT项的文件名起始位置。文件名正常：UNICODE码的“$MFT”。检查标准属性（10H），文件名属性（30H），数据流属性（80H）属性，到80属性的时候，发现从80属性开始的第三行开始，都被清零，其他的重要的四个元数据文件中，$Volume属性也出现了同样的错误。

找到备份的前四个元数据文件的记录。覆写错误的记录。根据DBR找到了MFT前四个元数据文件的备份，备份的元数据文件几乎跟前面四个一摸一样的错误。只能是手工修复$MFT。在$MFT自身的记录当中，发现”结束VCN”并没有遭到破坏，这为后期的修复工作节省了很多时间，复制一个正常分区（分区E)的第一个扇区到损坏的$MFT中，修改其中的一些数值。在80属性中，第三行字节的开始位置应该是描述的datarun的起始位置，根据起始VCN和结束VCN得出$MFT的大小，计算方法：起始 VCN+1=LCN，根据这个数值，写入datarun。将LCN * 8 * 512=0000FE6DH。分别写入偏移（想对于80H）48H,50H,和58H，如图：

写入方法：根据DBR中的描述的$MFT起始位置（000000C000H）786432号簇，$MFT的大小为VCN+1个簇，那么datarun就是 “33 E0 DF 06 00 00 0C 00H”，按同样的方法修复备份的$MFT的前四个元数据文件。

保存，重新载入分区，winhex打开，所有的元数据文件全部显示出来。文件、目录损都可以正常读取
提示“目录损坏且无法读取的原因有很多”。具体情况具体分析，以上方法仅供参考！

作者: 分区格式化 时间: 2010-4-24 18:45
高手就是高手,顶一个有时间给你学习一下

作者: 石头第七领域 时间: 2010-4-24 23:00
可见楼主对ntfs的文件系统非常熟悉，灵活运用winhex，受教了。
请问恢复的是几个分区，这种情况能用diskgen恢复成功吗？

作者: manhua 时间: 2010-4-25 10:13
人家是专门做这行的

作者: 北京令狐冲 时间: 2010-4-25 20:41
3# 石头第七领域 兄弟过奖了，此案例中不是分区丢失，而是文件系统结构损坏造成的。diskgenius目前虽然支持删除、格式化的恢复，但是效果还不是很理想（李大海先生还在逐步改进当中）。提示“文件或目录损坏且无法读取”这种情况现在很常见，对于破坏不严重的，可以直接运行chkdsk命令修复就行。如果破坏的严重，且数据非常重要，建议先手工修复，（chkdsk命令的修复能力有限）。在winhex下能看到文件及目录以后在执行命令（这样是为了保险起见），如果执行chkdsk命令修复不成功，会大大增加恢复的难度。

作者: nhqwsj 时间: 2010-4-25 20:46
兄弟，前面几个的图怎么没出来，最后一个图出来了

作者: 北京令狐冲 时间: 2010-4-25 20:54
6# nhqwsj
原来你也在这里！呵呵，最有一个图是编辑的时候弄错了。什么内容也没有！

作者: iargw2005 时间: 2010-4-30 01:45
这个看着仿佛有点费劲，我看了两遍没看明白，可能太菜了，不过还是谢谢了

欢迎光临迅维网 (https://www.chinafix.com/)