Windows 为什么文件属性目录是16，而不是8？

为什么Microsoft将值

0x8

（8，第3位）保留为默认值？

文件属性目录

0x10

（16，第4位）

位3是唯一保留的位。什么原因？

通常，保留值表示在过去的某个时刻，可能在早已不推荐使用的Windows发布版本中，或者在从未公开发布的开发版本中，该值用于某些目的，但该值不再具有意义

通过将该值标记为保留值，可以防止未来的开发人员重新使用该值。如果重新使用该值，则可能会导致遗留软件出现意外行为

在这种情况下，虽然您说第3位是保留的，但在头文件中我看不到这方面的任何证据。我拥有的头文件具有以下宏定义：

#define FILE_ATTRIBUTE_READONLY             0x00000001  
#define FILE_ATTRIBUTE_HIDDEN               0x00000002  
#define FILE_ATTRIBUTE_SYSTEM               0x00000004  
#define FILE_ATTRIBUTE_DIRECTORY            0x00000010  
#define FILE_ATTRIBUTE_ARCHIVE              0x00000020  
#define FILE_ATTRIBUTE_DEVICE               0x00000040  
#define FILE_ATTRIBUTE_NORMAL               0x00000080  
#define FILE_ATTRIBUTE_TEMPORARY            0x00000100  
#define FILE_ATTRIBUTE_SPARSE_FILE          0x00000200  
#define FILE_ATTRIBUTE_REPARSE_POINT        0x00000400  
#define FILE_ATTRIBUTE_COMPRESSED           0x00000800  
#define FILE_ATTRIBUTE_OFFLINE              0x00001000  
#define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED  0x00002000  
#define FILE_ATTRIBUTE_ENCRYPTED            0x00004000  
#define FILE_ATTRIBUTE_VIRTUAL              0x00010000  

我并没有由此推断第3位是保留的，只是它没有被使用

根据评论中的讨论，只读、隐藏、系统、目录和归档属性的值与DOS和FAT文件系统使用的类似值相同

例如，驱动程序具有以下宏声明：

#define FAT_DIRENT_ATTR_READ_ONLY        0x01
#define FAT_DIRENT_ATTR_HIDDEN           0x02
#define FAT_DIRENT_ATTR_SYSTEM           0x04
#define FAT_DIRENT_ATTR_VOLUME_ID        0x08
#define FAT_DIRENT_ATTR_DIRECTORY        0x10
#define FAT_DIRENT_ATTR_ARCHIVE          0x20
#define FAT_DIRENT_ATTR_DEVICE           0x40

因此，我们可以推断，当Windows API创建时，这些相同的值被继承，大概是为了让已经熟悉这些值的开发人员不必学习一组新的相互竞争的值。DOS/FAT中对应于位3的值没有直接模拟为Windows文件属性，因此未使用该值

不过，所有这些都是猜测，我怀疑您需要找到一位原始的Windows API开发人员来确认这一点。

通常保留值表示在过去的某个时候，可能在一个早已被弃用的Windows发布版本中，或者在一个从未公开发布的开发版本中，该值被用于某些目的，但该值不再具有意义

通过将该值标记为保留值，可以防止未来的开发人员重新使用该值。如果重新使用该值，则可能会导致遗留软件出现意外行为

在这种情况下，虽然您说第3位是保留的，但在头文件中我看不到这方面的任何证据。我拥有的头文件具有以下宏定义：

#define FILE_ATTRIBUTE_READONLY             0x00000001  
#define FILE_ATTRIBUTE_HIDDEN               0x00000002  
#define FILE_ATTRIBUTE_SYSTEM               0x00000004  
#define FILE_ATTRIBUTE_DIRECTORY            0x00000010  
#define FILE_ATTRIBUTE_ARCHIVE              0x00000020  
#define FILE_ATTRIBUTE_DEVICE               0x00000040  
#define FILE_ATTRIBUTE_NORMAL               0x00000080  
#define FILE_ATTRIBUTE_TEMPORARY            0x00000100  
#define FILE_ATTRIBUTE_SPARSE_FILE          0x00000200  
#define FILE_ATTRIBUTE_REPARSE_POINT        0x00000400  
#define FILE_ATTRIBUTE_COMPRESSED           0x00000800  
#define FILE_ATTRIBUTE_OFFLINE              0x00001000  
#define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED  0x00002000  
#define FILE_ATTRIBUTE_ENCRYPTED            0x00004000  
#define FILE_ATTRIBUTE_VIRTUAL              0x00010000  

我并没有由此推断第3位是保留的，只是它没有被使用

根据评论中的讨论，只读、隐藏、系统、目录和归档属性的值与DOS和FAT文件系统使用的类似值相同

例如，驱动程序具有以下宏声明：

#define FAT_DIRENT_ATTR_READ_ONLY        0x01
#define FAT_DIRENT_ATTR_HIDDEN           0x02
#define FAT_DIRENT_ATTR_SYSTEM           0x04
#define FAT_DIRENT_ATTR_VOLUME_ID        0x08
#define FAT_DIRENT_ATTR_DIRECTORY        0x10
#define FAT_DIRENT_ATTR_ARCHIVE          0x20
#define FAT_DIRENT_ATTR_DEVICE           0x40

因此，我们可以推断，当Windows API创建时，这些相同的值被继承，大概是为了让已经熟悉这些值的开发人员不必学习一组新的相互竞争的值。DOS/FAT中对应于位3的值没有直接模拟为Windows文件属性，因此未使用该值

不过，所有这些都是猜测，我怀疑您需要找到一位原始的Windows API开发人员来证实这一点。

基于一些非常重要的原因，我想我知道答案。从自身来看：

值8已用于卷ID，因此NT选择避免使用它。

基于一些非常重要的原因，我想我知道答案。从自身来看：

---

值8已用于卷ID，因此NT选择避免它。

位3是

FAT\u DIRENT\u ATTR\u volume\u ID

（8）。在FAT卷上，它在根目录中的文件内部设置，以存储卷标。请参阅示例fastfat文件系统驱动程序中的。另请参阅中关于属性8/位3的讨论，以查找文件（例如AH=11h和AH=4Eh）和创建文件（例如AH=16h和AX=6C00h）来查询和设置卷标。@eryksun这与文件属性值有何关系？这可能就是@eryksun:！请将您的评论更改为一条，以便我可以接受。好的，我可以猜到，当创建Windows API时，只读、隐藏、系统、目录和存档的值是从DOS的分析标志中转过来的。这就是为什么在第3位有一个洞，因为这个值没有通过Windows API。这是有道理的。尽管如此，我不认为

0x00000008

是以任何方式保留的，它只是还没有被使用。因为这是真正的文件，如果查找代码-它完全用作文件属性-位3是

FAT\u DIRENT\u ATTR\u VOLUME\u ID

（8）。在FAT卷上，它在根目录中的文件内部设置，以存储卷标。请参阅示例fastfat文件系统驱动程序中的。另请参阅中关于属性8/位3的讨论，以查找文件（例如AH=11h和AH=4Eh）和创建文件（例如AH=16h和AX=6C00h）来查询和设置卷标。@eryksun这与文件属性值有何关系？这可能就是@eryksun:！请将您的评论更改为一条，以便我可以接受。好的，我可以猜到，当创建Windows API时，只读、隐藏、系统、目录和存档的值是从DOS的分析标志中转过来的。这就是为什么在第3位有一个洞，因为这个值没有通过Windows API。这是有道理的。尽管如此，我不认为

0x00000008

是以任何方式保留的，它只是还没有被使用。因为这是真正的文件，如果查找代码-它完全用作文件属性-我保留了Windows NT的第一个DDK副本。它在ntddk.h内的一条注释中记录了该标志：“注意：0x00000008是为旧的DOS卷ID（卷ID）保留的，因此在NT中不被认为是有效的。”继续，在那里看不到任何内容。我为Windows NT保留了第一个DDK的副本。它在ntddk.h内的注释中记录了该标志：“注意：0x00000008是为旧DOS卷ID（卷ID）保留的，并且是