NTFS中的DirtyBit设置时机

看文章说NTFS对Dirty Bit设置是在只有出现严重的数据不一致，同时无法根据日志功能进行修复时才进行的。

我想问，这种不一致CHECK等功能是实时做的，还是关机的时候做的？

可以参考《走近文件系统系列二：探索Dirty Bit的奥秘》一文，转载自盆盆的博客

图片没有贴，详见原文


很多用户发现，同样是非法关机，重启时有些系统会自动进行磁盘检测（通常是FAT文件系统），而有些系统则照常启动（通常是NTFS文件系统）。

为什么？

原来不同的文件系统，对于Dirty Bit的设置方法有所区别，这种区别可以套用法律术语来类比：

(1) FAT相当于大陆法体系，实行的是“有罪推定”。在写入数据前，首先假设文件系统是“有罪”的──设置Dirty Bit为1。只有确认数据操作完成以后，才将Dirty Bit设置为0，如果非法关机时，Dirty Bit可能还保留为1，则下次开机会自动进行磁盘扫描。

(2) NTFS相当于英美法体系，实现的是“无罪推定”。只有出现严重的数据不一致，同时无法根据日志功能进行修复，这时候才会将Dirty Bit设置为1。

实验过程

1．工具箱

(1) Winhex：本文将用该工具查看、修改$Volume元数据文件。
      下载地址：http://www.x-ways.net/winhex/index-m.html

(2) Fsutil：该命令行工具可以对文件系统进行全方位的管理，本文将用该工具管理NTFS文件系统的Dirty Bit设置，然后借助WinHex来获知磁盘数据的底层信息。
      Windows XP/2003自带，对于Windows 2000，可以直接借用XP下的工具。

2．实验步骤

由于Windows对NTFS的元数据文件进行保护，所以我们无法直接在Windows系统里访问$Volume，但是我们可以借助第三方磁盘工具Winhex绕开这个系统限制，来达到目的。

在这个实验里，我们借助Winhex访问NTFS卷的$Volume文件，以确认Dirty Bit到底对应$Volume文件的哪个地方。

(1) 用Winhex打开任意一个卷，例如D盘，即可看到D盘里的所有元数据文件，例如$MFT、$MFTMirr、$Volume等文件。双击其中的$Volume即可打开该文件。

(2) 大家知道，每个NTFS文件都是由若干属性所组成。$Volume 文件具有两个独有的属性，$VOLUME_NAME和$VOLUME_INFORMATION。其中卷标是由$VOLUME_NAME定义，而Dirty bit则是由$VOLUME_INFORMATION属性所定义的。$VOLUME_INFORMATION属性如下图所示，开头的值70H表示该属性的类别，offset 4的值28H定义该属性的长度，相当于十进制的40。

(3) 为了清楚的标识$VOLUME_INFORMATION属性，现将该属性单独截图如下。第三方最左侧的两个字节（offset为32-33）定义了NTFS文件系统的版本号，本例中的值为03 01，代表NTFS 3.1版（Windows XP是3.1版本，而Windows 2000则是3.0）。

(4) 为了找出Dirty Bit到底在哪里，我们可以借助Fsutil命令人为地制造一个Dirty Bit。在命令提示符下运行以下命令：

Fsutil dirty set D:

刷新Winhex的视图，可以看到$VOLUME_INFORMATION属性的值出现了变化，如下图所示。

可以得出这样的猜想：offset 34的字节定义了NTFS文件系统的Dirty Bit设置情况，当该值为01时，代表NTFS文件系统设置了Dirty Bit。

3．逆向验证

为了证实这个结果，需要进行逆向验证。可以将$VOLUME_INFORMATION属性中Offset 34字节的值直接修改为01，看看是否相当于设置Dirty Bit的状态位。

(1) 直接在Winhex里修改Offset 34字节的值，将其设置为01，同时保存所做的设置。

(2) 然后在命令提示符下运行以下命令，查看Dirty Bit的设置状态：

Fsutil dirty query D:

出乎意料的是，命令查询的结果是“卷 - D: 没有损坏”，也就是说Fsutil命令并不认为文件系统设置了Dirty Bit。

(3) 单击开始→关闭计算机→重新启动，发现系统开始自动扫描。看来尽管Fsutil命令并没有认可我们的手动设置，但是实际还是生效的。

不一致的Check好象是是实时处理的，记得在《数据恢复技术》里看到过