走近文件系统系列二：探索Dirty Bit的奥秘
在微软知识库文章KB322275上看到如下的一段话：
The "dirty" bit is a bit in the boot sector (for FAT or FAT32 volumes), or in the MFT (for NTFS volumes), that is checked when Windows starts.
这说明，在FAT文件系统里，Dirty Bit在分区的引导扇区（Boot Sector）中指定；而在NTFS文件系统里，则是在MFT中指定（实际上是$Volume元数据文件）。
作为一名IT Pro，自然不仅仅满足于知道以上的结论。本着“绝知此事要躬行”的精神，本文介绍如何通过工具，找出在$Volume元数据文件中的哪个地方定义了这个Dirty Bit。
名词解释
什么是Dirty Bit？它实际上是文件系统的一个错误状态位，Windows启动时会根据这个状态位来判断文件系统是否出了故障，以确定是否要运行Chkdsk /F来进行磁盘修复。
行为差别
很多用户发现，同样是非法关机，重启时有些系统会自动进行磁盘检测（通常是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命令并没有认可我们的手动设置，但是实际还是生效的。
4．疑难解答
(1) 为什么Fsutil命令无法查询手动设置Dirty Bit？
可能的答案是，在系统Mount分区的时候，先将重要的元数据文件（包括$Volume）读到内存里，而Fsutil命令会从内存里（而不是磁盘里）读取Dirty Bit的设置情况。手动修改$Volume后，系统并没有重新将新的$Volume读入内存，所以Fsutil命令无法查询Dirty Bit的设置情况。
(2) 如何才能迫使系统重新读入元数据文件？
可以尝试在“磁盘管理”管理单元里删除该卷的盘符（本例为D:），然后重新恢复盘符。设置以后，Fsutil命令果然可以正确读取Dirty Bit的状态了。
(3) 手动设置Dirty Bit，重启系统后会自动运行Chkdsk /F，为什么会提示元数据文件$MFTMirr错误？
$MFTMirr保存着$MFT中前面四个文件记录，其中包括$Volume。前面的实验过程并没有同步修改$MFTMirr中的$Volume，导致两者记录不一致。
实用价值
当然，本文提到手动设置Dirty Bit的方法只是为了实验验证，并没有真正的应用价值，我们没有必要采用这种方法进行手动设置。
明明是正常关机，但是每次开机时会自动询问是否扫描磁盘。遇到这种问题，可以按照以下步骤进行处理（参考KB160963）：
(1) 运行Fsutil dirty query DriveLetter命令，检查该磁盘是否设置了Dirty Bit。如果是的话，可能是硬盘本身的问题，请联系硬盘厂商或者计算机经销商进行检测。
如果需要防止系统自动检测标记Dirty Bit的卷，可以运行以下命令进行排除：
chkntfs /x DriveLetter
(2) 检查任务计划、启动项里有没有相应的加载项，有的话删除即可。
(3) 打开注册表编辑器，进入以下注册表项：
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\CONTROL\Session Manager
检查其下的多字符串键值BootExecute，是否为类似以下的数值数据：
autocheck autochk /r \??\D:
如果是的话，删除其中/r \??\D:即可。
提示
在NTFS文件系统里，有一句很著名的话“everything on the disk is a file”，所有的文件系统数据，都是文件，包括MFT、引导扇区、甚至还有安全描述符等。
关于NTFS文件系统的元数据文件的描述，可以参考以下的微软官方文档：
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/8cc5891d-bf8e-4164-862d-dac5418c5948.mspx
又及：是夜无风，有月，遂摄衣出户，月色如水，乱竹皆白，乃记之。