提示“目录或文件损坏且无法读取”的恢复

lqandy · 发表于 2009-11-18 15:39:43

太好了上次碰到这个问题重装了

cadwap · 发表于 2009-11-18 22:13:44

了解一点点,还要慢慢消人化才行.顶上了.

sunfuxin · 发表于 2009-11-19 00:48:29

这种丢数据情况还是比较常见的，突然断电经常会这样，但问题所在并不一定是这样的，尤其对于NTFS而言，内部很复杂，不知哪里不对就提示文件错误了，你运气好，这个明显的地方出错了。

comtery · 发表于 2009-11-19 11:10:59

提示: 作者被禁止或删除内容自动屏蔽

小丁 · 发表于 2009-11-19 12:24:21

看不懂。。。。。。

wnving · 发表于 2009-11-19 19:01:06

这种丢数据情况还是比较常见的，突然断电经常会这样，但问题所在并不一定是这样的，尤其对于NTFS而言，内部很复杂，不知哪里不对就提示文件错误了，你运气好，这个明显的地方出错了。
sunfuxin 发表于 2009-11-19 00:48

登录/注册后可看大图

受教了，不过我已经看过1G多的源代码，对于NTFS我多少了解一点.............
请认真看最后一句话.......我的目的是跟大家交流心得，分享解决思路，而并非炫耀.......

harsonshi · 发表于 2009-11-20 09:03:52

学习一下,多谢楼主了

573080453 · 发表于 2009-11-20 09:49:59

谢谢分享啊

leiyu23 · 发表于 2009-11-20 12:27:08

最近一直比較忙,很久沒有回來逛逛了,呵呵.感謝冷狐兄弟分享經驗,.
转到第分区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属性也出现了同样的错误。

812021056 · 发表于 2009-11-20 15:32:36

谢谢，从大哥的贴子里我学到了很多东西，谢谢