文件删除数据恢复 NTFS RUNLIST及数据删除过程
本帖最后由 wzlr 于 2016-7-17 14:53 编辑NTFS RUNLIST，心痒痒，聊聊为什么NTFS删除大文件后FILE RECORD大小表现为0？
原因在于：NTFS删除一个文件，必须要完成如下几个流程，才算完结：
1、更改文件系统$bitmap，释放空间
2、更改$mft filerecord项的属性为删除
3、更改$mft:$bitmap的位图信息为0，释放这个filerecord的占用空间
4、清除目录链表中关于本文件的item信息。
这个流程是理想状态下的处理规则，但实际上，最头疼的是OS要考虑这个问题：如果在上述4个步骤中出现中断(如突然断电、死机等)，如何让下次操作时能够继续，或者维系文件系统还是一致的(最简单的，如果文件删除了，但目录还在，那总是不合适的，全盘李检测一次又太消耗时间，而且到底谁错了，有时候也分不清)，为了解决这个问题，NTFS引入了$logfile，即日志，简单说就是为正在执行的一个完整IO运作(如删除一个文件)事先记录一下状态，如果没做成功，下回直接回滚回没做成功的状态即可。
可是问题又来了，如果某个文件太大，或者存储链表太长(即碎片太多)。记录这个文件元信息部分就会变得很大，比如一个文件大小是4G，按4K块大小算，连续的位图至少也得有1M，为了不至于在日志文件中保存太大的信息(比如一个4T的文件，先保存1g的位图，太慢且变数又增大了)，NTFS对于复杂文件或大文件是采取分批次处理的：即某个文件可能是不断地被变小，变小，直至变0。
为了维持操作的一致性。猜想，NTFS设了两种情况，如果是判断可以一次日志记录即够完成某个IO原子操作的，就不用清除filerecord的大小和位置信息(runlist)了。但如果ntfs无法一次日志完成一个IO原子操作，则需要分成多个独立的IO原子操作，每个IO原子操作记录一次日志，完成时更新成新状态——这样一来，删除一个大文件或多碎片的文件，最后一次IO原子操作后，就会清除为0大小，RUNLIST清空状态。
chk如果是fat文件系统，简单—用winhex查找需要恢复的文件名，能找到子目录，根据子目录，再找父目录，一层一层找，就能找到出错的目录位置，直接在dbr中把这个目录定义成根目录，一刷新数据就出来了。
如果是ntfs，如果目录丢了，扫描也没用。 多谢分享经验 没讲完呀（1： 多谢分享经验 多谢分享经验 多谢分享经验
页:
[1]