为何FILE_ATTRIBUTE_DIRECTORY为16而非8？微软预留0x8属性位的原因？

作为长期和Windows API打交道的开发者，这两个问题本质上都绕不开历史兼容性——Windows的文件属性系统是从DOS一步步演化来的，很多设计决策都得照顾老程序的死活。

1. 为什么FILE_ATTRIBUTE_DIRECTORY是0x10（16）而不是0x8（8）？ #

回到DOS 1.x的时代，文件属性位的分配已经定死了：

• 0x1：只读（FILE_ATTRIBUTE_READONLY）
• 0x2：隐藏（FILE_ATTRIBUTE_HIDDEN）
• 0x4：系统（FILE_ATTRIBUTE_SYSTEM）
• 0x8：卷标（Volume Label）

DOS用0x8位来标记根目录里的卷标条目——这玩意儿不是真正的文件/目录，但DOS需要用这个位把它和普通文件区分开。等到后来需要给目录加专属属性的时候，0x8已经被卷标占了。要是硬把目录属性塞到0x8位，那些依赖这个位识别卷标的老程序直接就会把目录当成卷标处理，各种逻辑错误就来了。所以微软只能选下一个空着的位0x10，这就成了我们现在用的FILE_ATTRIBUTE_DIRECTORY。

2. 微软为什么预留0x8位？它的用途是什么？ #

首先，0x8位最初是给DOS卷标用的，但到了NTFS时代，卷标的实现方式变了——它变成了一个特殊的元文件$Volume，不再靠0x8属性位来标识。但这个位并没有被复用给其他属性，核心原因还是兼容性：大量DOS和16位Windows老程序还在检查这个位来判断条目是不是卷标，要是把它分给别的属性，这些老程序直接就崩了。

微软把它标记为“唯一预留位”，一方面是为了守住向后兼容的底线，另一方面也可能是留作未来的潜在扩展用途，但这么多年过去这个位一直没被启用过。目前来看，它的主要作用就是“占坑”，防止新的属性不小心占用这个位，破坏遗留程序的逻辑。

内容的提问来源于stack exchange，提问作者Michel de Ruiter