Why is FILE_ATTRIBUTE_DIRECTORY 16, not 8?

Question

Why did Microsoft reserve the value 0x8 (8, bit 3) as a File Attribute Constant? FILE_ATTRIBUTE_DIRECTORY is 0x10 (16, bit 4).

Bit 3 is the only reserved bit. For what?

Answer 1

Based on some very useful comments, I think I know the answer. From wdm.h itself:

//
// Define the file attributes values
//
// Note:  0x00000008 is reserved for use for the old DOS VOLID (volume ID)
//        and is therefore not considered valid in NT.
//...

#define FILE_ATTRIBUTE_READONLY             0x00000001  
#define FILE_ATTRIBUTE_HIDDEN               0x00000002  
#define FILE_ATTRIBUTE_SYSTEM               0x00000004  
//OLD DOS VOLID                             0x00000008

#define FILE_ATTRIBUTE_DIRECTORY            0x00000010  
#define FILE_ATTRIBUTE_ARCHIVE              0x00000020  
#define FILE_ATTRIBUTE_DEVICE               0x00000040  
#define FILE_ATTRIBUTE_NORMAL               0x00000080  
...

The value 8 had been used for the volume ID, so NT chose to avoid it.

Answer 2

Usually a reserved value indicates that at some point in the past, perhaps in a released version of Windows that has long since been deprecated, or perhaps in a development version that was never publicly released, that value was used for some purpose, but the value no longer has meaning.

By marking the value as reserved, future developers are prevented from re-using that value. Were that value to be re-used then it could lead to unexpected behaviour in legacy software.

In this case, whilst you say that bit 3 is reserved, I cannot see any evidence of that in the header file. The header file I have has these macro definitions:

#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  

I don't infer from this that bit 3 is reserved, just that it is not used.

Based on the discussion from the comments, the values of the read only, hidden, system, directory and archive attributes are the same as the analogous values used by DOS and the FAT file system.

For example, the sample fastfat filesystem driver has these macro declarations:

#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

So we might infer that when the Windows API was created, these same values were carried forward, presumably so that developers who were already familiar with the values did not have to learn a new competing set of values. The value corresponding to bit 3 in DOS/FAT did not have a direct analogue as a Windows file attribute, so it was left unused.

All of this is speculation though, and I suspect that you'd need to find one of the original Windows API developers to confirm this.