昨天，我无意间运行了一下chkdsk，结果竟然报告有错误，需要使用chkdsk /F来进行修复。系统是Windows XP Pro SP2
IBMOEM简体中文版，操作系统所在的这个C:盘是ntfs文件系统。我印象中ntfs是不太有磁盘错误（硬盘物理损坏另当别论）这种情况的，因为ntfs本身就具备强大的日志和自动修复功能。
有了问题了当然要修复。于是运行chkdsk /F，chkdsk报告说无法锁定当前驱动器，需要在下次启动时候运行chkdsk。这是意料之中的，因为当前这个分区是系统所做的分区。那就重启动吧。
重启动，chkdsk自动运行，过程好像挺顺利，很诀结束并再次重启，进入图形界面。
出于习惯，我再次运行chkdsk，看看现在有没有问题了。令我有点惊讶的事情发生了，chkdsk还是报告说有问题，需要用/F参数来修复。具体的输出信息与上次一样：
文件系统的类型是 NTFS。
卷标是 IBM_PRELOAD。
警告! 没有指定
F 参数
用只读模式运行 CHKDSK。
CHKDSK 正在校验文件(3 的阶段 1)...
文件校验完成。00。
CHKDSK 正在校验索引(3 的阶段 2)...
索引校验完成。00。
CHKDSK 正在校验安全描述符(3 的阶段 3)...
安全描述符校验完成。
CHKDSK 正在验证 Usn 日志...
正在修复 Usn 日志文件记录片段。
Usn 日志验证完成。
正在修复卷位图的错误。
Windows 发现文件系统有问题。
运行 CHKDSK (使用选项 /F) 来更正这些问题。
总共有
15361888 KB 磁盘空间。
50102 个文件中有
8879952 KB。
4128 个索引
25600 KB。
不正确扇区
0 KB。
系统正在使用
145968 KB。
日志文件占用了
65536 KB。
磁盘上
6310368 KB 可用。
每个分配单元中有
4096 字节。
磁盘上共有
3840472 个分配单元。
磁盘上有
1577592 个可用的分配单元。
心想，难道硬盘有物理故障了？这可是才用了约3个月的新硬盘呀。再修复一次试试？！
于是继续用chkdsk /F，重启动自动chkdsk。再次重启进入界面。然后再用chkdsk看看，问题依旧。
我就这样重新启动了4、5次，但是都没有解决问题。chkdsk总是报告说有问题，需要用/F修复，然而真用了/F但还是没有修复问题。
我想到了重新用IBM的ThinkVantage恢复一次，可我新恢复系统才几天啊！还是先上网查查吧。于是我找到了这样一篇博文：http://hi.baidu.com/fan856/blog/item/a9cdab51bea71c18377abef1.html
作者不久前也遇到了类似的问题，他在网上找到了一个老外的博客网页： [url=]http://mike.steinbaugh.com/journal/2002/08/28/ntfs-file-system-glitch.html[/url]
老外文章的大意是这样的。
这个博客的主人也遇到了这个问题，难以解决。于是他寻求微软的技术支持。微软答复说，ntfs上的chkdsk的确有这个问题。
当用chkdsk检查ntfs卷时，也会检查主控文件表(MFT)中的安全描述子(security descriptor)数据库，如果发现有的安全描述子库不被任何文件所引用，chkdsk就会输出这个错误信息。
进一步的解释。当我们对ntfs卷上的文件、目录设置访问权限时，系统会在该卷的MFT中创建一个唯一的安全描述子库，用以描述这些权限设置，并且对这个文件或目录创建一个引用（类似于指针），指向这个安全描述子库。这样就完成了对这个目录或文件的权限设置。
然而，如果以后不再使用这些安全描述子库（注：我理解为，撤销了这些额外的权限设置），那么这些安全描述子库并不会被删除，而是继续保留。因为，有可能它们还会被使用，就像所有的Cache策略一样。
然后问题就出现了，chkdsk检测出这些安全描述子库不被任何文件所引用，但还占据在MFT中，所以认为是“主控文件表(MFT)位图中有标记为已分配的可用空间”。
可以说，这是chkdsk将一个比较正常的现象当作故障来报告了，而且它也没办法修复，其实也不必修复。
了解了这些，我们也可以知道，这就不必要去“解决”了，因为本质上也没有什么问题。
当然，从软件完善的角度来说，chkdsk这样的输出肯定是不妥当的，小题大做，引起用户的“恐慌”。看看网上那么多对这个问题求助的帖子，就知道了。
看那个老外的博客上的文章，他贴出这个帖子（当时已经解决）是2002年8月28日，当时微软就是这么回复他的。但直到现在，都WinXP SP2了，微软依然不进行任何修正。这好像也太不应该了吧。
[复制链接]
发表于 2010-8-21 10:14:46
楼主