XFAT - Technical Design - Directory Table - Directory Entry

Directory Entry

Before Microsoft added support for long filenames and creation/access time stamps, bytes 0x0C0x15 of the directory entry were used by other operating systems to store additional metadata, most notably the operating systems of the Digital Research family stored file passwords, access rights, owner IDs, and file deletion data there. While Microsoft's newer extensions are not fully compatible with these extensions by default, most of them can coexist in third-party FAT implementations (at least on FAT12 and FAT16 volumes).

Directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3 filename):

Byte Offset Length (bytes) Description
0x00 8 Short file name (padded with spaces)

The first byte can have the following special values:

Value Description
0x00 Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS/PC DOS 1.0, but not in 86-DOS).
0x05 Initial character is actually 0xE5. (since DOS 3.0)

Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, 0x05 is also used for pending delete files under DELWATCH. Once they are removed from the deletion tracking queue, the first character of an erased file is replaced by 0xE5.

0x2E 'Dot' entry; either "." or ".." (since DOS 2.0)
0xE5 Entry has been previously erased and is available. File undelete utilities must replace this character with a regular character as part of the undeletion process. See also: 0x05.

(The reason, why 0xE5 was chosen for this purpose in 86-DOS is down to the fact, that 8-inch CP/M floppies came pre-formatted with this value filled and so could be used to store files out-of-the box.)

Versions of DOS prior to 5.0 start scanning directory tables from the top of the directory table to the bottom. In order to increase chances for successful file undeletion, DOS 5.0 and higher will remember the position of the last written directory entry and use this as a starting point for directory table scans.

0x08 3 Short file extension (padded with spaces)
0x0B 1 File Attributes
Bit Mask Description
0 0x01 Read Only. (Since DOS 2.0) If this bit is set, the operating system will not allow a file to be opened for modification.

Deliberately setting this bit for files which will not be written to (executables, shared libraries and data files) may help avoid problems with concurrent file access in multi-tasking, multi-user or network environments with applications not specifically designed to work in such environments (i.e. non-SHARE-enabled programs).

1 0x02 Hidden. Hides files or directories from normal directory views.

Under DR DOS 3.31 and higher, under PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, REAL/32, password protected files and directories also have the hidden attribute set. Password-aware operating systems should not hide password-protected files from directory views, even if this bit may be set. The password protection mechanism does not depend on the hidden attribute being set up to including DR-DOS 7.03, but if the hidden attribute is set, it should not be cleared for any password-protected files.

2 0x04 System. Indicates that the file belongs to the system and must not be physically moved (f.e. during defragmentation), because there may be references into the file using absolute addressing bypassing the file system (boot loaders, kernel images, swap files, extended attributes, etc.).
3 0x08 Volume Label. (Since DOS 2.0) Indicates an optional directory volume label, normally only residing in a volume's root directory. Ideally, the volume label should be the first entry in the directory (after reserved entries) in order to avoid problems with VFAT LFNs. If this volume label is not present, some systems may fall back to display the partition volume label instead, if a EBPB is present in the boot sector (not present with some non-bootable block device drivers, and possibly not writeable with boot sector write protection). Even if this volume label is present, partitioning tools like FDISK may display the partition volume label instead. The entry occupies a directory entry but has no file associated with it. Volume labels have a filesize entry of zero.

Pending delete files and directories under DELWATCH have the volume attribute set until they are purged or undeleted.

4 0x10 Subdirectory. (Since DOS 2.0) Indicates that the cluster-chain associated with this entry gets interpreted as subdirectory instead of as a file. Subdirectories have a filesize entry of zero.
5 0x20 Archive. (Since DOS 2.0) Typically set by the operating system as soon as the file is created or modified to mark the file as "dirty", and reset by backup software once the file has been backed up to indicate "pure" state.
6 0x40 Device (internally set for character device names found in filespecs, never found on disk), must not be changed by disk tools.
7 0x80 Reserved, must not be changed by disk tools.

Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, the volume attribute is set for pending delete files and directories under DELWATCH.

An attribute combination of 0x0F is used to designate a VFAT long file name entry since MS-DOS 7.0. Older versions of DOS can mistake this for a directory volume label, as they take the first entry with volume attribute set as volume label. This problem can be avoided if a directory volume label is enforced as part of the format process; for this reason some disk tools explicitly write dummy "NO␠NAME␠␠␠␠" directory volume labels when the user does not specify a volume label. Since volume labels normally don't have the system attribute set at the same time, it is possible to distinguish between volume labels and VFAT LFN entries. The attribute combination 0x0F could occasionally also occur as part of a valid pending delete file under DELWATCH, however on FAT12 and FAT16 volumes, VFAT LFN entries always have the cluster value at 0x1A set to 0x0000 and the length entry at 0x1C is never 0x00000000, whereas the entry at 0x1A is always non-zero for pending delete files under DELWATCH (with the possible exception of zero-length files or deleted files following the FAT16+ proposal indicated by 0x00000000 at 0x1C). This check does not work on FAT32 volumes.

0x0C 1
  • CP/M-86 and DOS Plus store user attributes F1'—F4' here. (DOS Plus 1.2 with BDOS 4.1 supports passwords only on CP/M media, not on FAT12 or FAT16 media. While DOS Plus 2.1 supported logical sectored FATs with a partition type 0xF2, FAT16B and FAT32 volumes were not supported by these operation systems. Even if a partition would have been converted to FAT16B it would still not be larger than 32 MB. Therefore, this usage is not conflictive with FAT32.IFS or FAT+, as they can never occur on the same type of volume.):
Bit Mask Description
7 0x80 F1': Modify default open rules
6 0x40 F2': Partial close default
5 0x20 F3': Ignore Close Checksum Error
4 0x10 F4': Disable checksums
3 0x08 Reserved
2 0x04 Delete requires password
1 0x02 Write requires password
0 0x01 Read requires password
  • MSX-DOS 2: For a deleted file, the original first character of the filename. For the same feature in various other operating systems, see offset 0x0D if enabled in MSX boot sectors at sector offset 0x026. MSX-DOS supported FAT12 volumes only, but third-party extensions for FAT16 volumes exist. Therefore, this usage is not conflictive with FAT32.IFS and FAT32+ below. It does not conflict with the usage for user attributes under CP/M-86 and DOS Plus as well, since they are no longer important for deleted files.
  • Windows NT and later versions uses bits 3 and 4 to encode case information (see below); otherwise 0.
  • DR-DOS 7.0x reserved bits other than 3 and 4 for internal purposes since 1997. The value should be set to 0 by formating tools and must not be changed by disk tools.
  • On FAT32 volumes under OS/2 and eComStation the third-party FAT32.IFS driver utilizes this entry as a mark byte to indicate the presence of extra "␠EA.␠SF" files holding extended attributes with parameter /EAS. Version 0.70 to 0.96 used the magic values 0x00 (no EAs), 0xEA (normal EAs) and 0xEC (critical EAs), whereas version 0.97 and higher since 2003-09 use 0x00, 0x40 (normal EAs) and 0x80 (critical EAs) as bitflags for compatibility with Windows NT.
  • Bits other than 3 and 4 are utilized by FAT+, a proposal how to store files larger than 4 GB on FAT32 (and FAT16B) volumes. This is critically conflictive with FAT32.IFS.
0x0D 1
  • First character of a deleted file under Novell DOS, OpenDOS and DR-DOS 7.02 and higher. A value of 0xE5 (229), as set by DELPURGE, will prohibit undeletion by UNDELETE, a value of 0x00 will allow conventional undeletion asking the user for the missing first filename character. S/DOS 1 and PTS-DOS 6.51 and higher also support this feature if enabled with SAVENAME=ON in CONFIG.SYS. For the same feature in MSX-DOS, see offset 0x0C.
  • Create time, fine resolution: 10 ms units, values from 0 to 199 (since DOS 7.0 with VFAT).

Double usage for create time ms and file char is not conflictive, since the creation time is no longer important for deleted files.

0x0E 2
  • Under DR DOS 3.31 and higher including PalmDOS, Novell DOS and OpenDOS as well as under Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 and possibly also under FlexOS, 4680 OS, 4690 OS any non-zero value indicates the password hash of a protected file, directory or volume label. The hash is calculated from the first eight characters of a password. If the file operation to be carried out requires a password as per the access rights bitmap stored at offset 0x14, the system tries to match the hash against the hash code of the currently set global password (by PASSWORD /G) or, if this fails, tries to extract a semicolon-appended password from the filespec passed to the operating system and checks it against the hash code stored here. A set password will be preserved even if a file is deleted and later undeleted.
  • Create time (since DOS 7.0 with VFAT). The hour, minute and second are encoded according to the following bitmap:

Bits Description
15-11 Hours (0-23)
10-5 Minutes (0-59)
4-0 Seconds/2 (0-29)
The seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0D.

If bits 15-11 > 23 or bits 10-5 > 59 or bits 4-0 > 29 here, or when bits 12-0 at offset 0x14 hold an access bitmap and this is not a FAT32 volume or a volume using OS/2 Extended Attributes, then this entry actually holds a password hash, otherwise it can be assumed to be a file creation time.

0x10 2
  • FlexOS, 4680 OS and 4690 OS store a record size in the word at entry 0x10. This is mainly used for their special database-like file types random file, direct file, keyed file, and sequential file. If the record size is set to 0 (default) or 1, the operating systems assume a record granularity of 1 byte for the file, for which it will not perform record boundary checks in read/write operations.
  • With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified time stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x0E for a format description.
  • Create date (since DOS 7.0 with VFAT). The year, month and day are encoded according to the following bitmap:

Bits Description
15-9 Year (0 = 1980, 119 = 2099 supported under DOS/Windows, theoretical up to 127 = 2107)
8-5 Month (1–12)
4-0 Day (1–31)

The usage for creation date for existing files and last modified time for deleted files is not conflictive because they are never used at the same time. For the same reason, the usage for the record size of existing files and last modified time of deleted files is not conflictive as well. Creation dates and record sizes cannot be used at the same time, however, both are stored only on file creation and never changed later on, thereby limiting the conflict to FlexOS, 4680 OS and 4690 OS systems accessing files created under foreign operating systems as well as potential display or file sorting problems on systems trying to interpret a record size as creation time. To avoid the conflict, the storage of creation dates should be an optional feature of operating systems supporting it.

0x12 2
  • FlexOS, 4680 OS, 4690 OS, Multiuser DOS, System Manager, REAL/32 and DR DOS 6.0 and higher with multi-user security enabled use this field to store owner IDs. Offset 0x12 holds the user ID, 0x13 the group ID of a file's creator.
In multi-user versions, system access requires a logon with account name and password, and the system assigns group and user IDs to running applications according to the previously set up and stored authorization info and inheritance rules. For 4680 OS and 4690 OS, group ID 1 is reserved for the system, group ID 2 for vendor, group ID 3 for the default user group. Background applications started by users have a group ID 2 and user ID 1, whereas operating system background tasks have group IDs 1 or 0 and user IDs 1 or 0. IBM 4680 BASIC and applications started as primary or secondary always get group ID 2 and user ID 1. When applications create files, the system will store their user ID and group ID and the required permissions with the file.
  • With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified date stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x10 for a format description.
  • Last access date (since DOS 7.0 if ACCDATE enabled in CONFIG.SYS for the corresponding drive); see offset 0x10 for a format description.

The usage for the owner IDs of existing files and last modified date stamp for deleted files is not conflictive because they are never used at the same time. The usage of the last modified date stamp for deleted files and access date is also not conflictive since access dates are no longer important for deleted files, however, owner IDs and access dates cannot be used at the same time.

0x14 2
  • Access rights bitmap for world/group/owner read/write/execute/delete protection for password protected files, directories (or volume labels) under DR DOS 3.31 and higher, including PalmDOS, Novell DOS and OpenDOS, and under FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager, and REAL/32.
Typical values stored on a single-user system are 0x0000 (PASSWORD /N for all access rights "RWED"), 0x0111 (PASSWORD /D for access rights "RW?-"), 0x0555 (PASSWORD /W for access rights "R-?-") and 0x0DDD (PASSWORD /R for files or PASSWORD /P for directories for access rights "--?-"). Bits 1, 5, 9, 12-15 will be preserved when changing access rights. If execute bits are set on systems other than FlexOS, 4680 OS or 4690 OS, they will be treated similar to read bits. (Some versions of PASSWORD allow to set passwords on volume labels (PASSWORD /V) as well.)
Single-user systems calculate the most restrictive rights of the three sets (DR DOS up to 5.0 used bits 0-3 only) and check if any of the requested file access types requires a permission and if a file password is stored. If not, file access is granted. Otherwise the stored password is checked against an optional global password provided by the operating system and an optional file password provided as part of the filename separated by a semicolon (not under FlexOS, 4680 OS, 4690 OS). If neither of them is provided, the request will fail. If one of them matches, the system will grant access (within the limits of the normal file attributes, that is, a read-only file can still not be opened for write this way), otherwise fail the request.
Under FlexOS, 4680 OS and 4690 OS the system assigns group and user IDs to applications when launched. When they request file access, their group and user IDs are compared with the group and user IDs of the file to be opened. If both IDs match, the application will be treated as file owner. If only the group ID matches, the operating system will grant group access to the application, and if the group ID does not match as well, it will grant world access. If an application's group ID and user ID are both 0, the operating system will bypass security checking. Once the permission class has been determined, the operating system will check if any of the access types of the requested file operation requires a permission according to the stored bitflags of the selected class owner, group or world in the file's directory entry. Owner, group and world access rights are independent and do not need to have diminishing access levels. Only, if none of the requested access types require a permission, the operating system will grant access, otherwise it fails.
If multiuser file / directory password security is enabled the system will not fail at this stage but perform the password checking mechanism for the selected permission class similar to the procedure described above. With multi-user security loaded many utilities since DR DOS 6.0 will provide an additional /U:name parameter.
File access rights bitmap:
Bit Mask Description
0 0x0001 Owner delete/rename/attribute change requires permission
1 0x0002 Owner execute requires permission (FlexOS, 4680 OS, 4690 OS only)
2 0x0004 Owner write/modify requires permission
3 0x0008 Owner read/copy requires permission
4 0x0010 Group delete/rename/attribute change requires permission
5 0x0020 Group execute requires permission (FlexOS, 4680 OS, 4690 OS only)
6 0x0040 Group write/modify requires permission
7 0x0080 Group read/copy requires permission
8 0x0100 World delete/rename/attribute change requires permission
9 0x0200 World execute requires permission (FlexOS, 4680 OS, 4690 OS only)
10 0x0400 World write/modify requires permission
11 0x0800 World read/copy requires permission
12-15 bits must be set to 0 during format and must not be modified by disk tools later on; bit 15 is used internally, but not on disk
File renames require either write or delete rights, IBM 4680 BASIC CHAIN requires execute rights.
  • Extended Attributes handle (used by OS/2 1.2 and higher as well as by Windows NT) in FAT12 and FAT16; first cluster of EA file or 0, if not used. A different method to store extended attributes has been devised for FAT32 volumes, see FAT32.IFS under offset 0x0C.
  • High two bytes of first cluster number in FAT32; with the low two bytes stored at offset 0x1A.

The storage of the high two bytes of the first cluster in a file on FAT32 is partially conflictive with access rights bitmaps.

0x16 2
  • Last modified time (since DOS 1.1); see offset 0x0E for a format description.
  • Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion time of pending delete files or directories under DELWATCH 2.00 or higher. The last modified time stamp is copied to 0x10 for possible later restoration. See offset 0x0E for a format description.
0x18 2
  • Last modified date; see offset 0x10 for a format description.
  • Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion date of pending delete files or directories under DELWATCH 2.00 or higher. The last modified date stamp is copied to 0x12 for possible later restoration. See offset 0x10 for a format description.
0x1A 2 Start of file in clusters in FAT12 and FAT16. Low two bytes of first cluster in FAT32; with the high two bytes stored at offset 0x14.

Entries with the Volume Label flag, subdirectory ".." pointing to FAT12/FAT16 root, and empty files with size 0 should have first cluster 0.

VFAT LFN entries also have this entry set to 0; on FAT12 and FAT16 volumes this can be used as part of a detection mechanism to distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.

0x1C 4 File size in bytes. Entries with the Volume Label or Subdirectory flag set should have a size of 0.

VFAT LFN entries never store the value 0x00000000 here. This can be used as part of a detection mechanism to distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.

For files larger than 4 GB following the FAT+ proposal, this entry only holds the size of the last chunk of the file (that is bits 31-0). The most significant bits 37-32 are stored in the entry at offset 0x0C.

The FlexOS-based operating systems IBM 4680 OS and IBM 4690 OS support unique distribution attributes stored in some bits of the previously reserved areas in the directory entries:

  1. Local: Don't distributed file but keep on local controller only.
  2. Mirror file on update: Distribute file to server only when file is updated.
  3. Mirror file on close: Distribute file to server only when file is closed.
  4. Compound file on update: Distribute file to all controllers when file is updated.
  5. Compound file on close: Distribute file to all controllers when file is closed.

Some incompatible extensions found in some operating systems include:

Byte Offset Length (bytes) System Description
0x0C 2 RISC OS File type, 0x00000x0FFF
0x0C 4 Petrov DOSFS File load address
0x0E 2 ANDOS File address in the memory
0x10 4 Petrov DOSFS File execution address

Read more about this topic:  XFAT, Technical Design, Directory Table

Other articles related to "directory entry, directory":

Link (Unix)
... creates a hard link from an existing directory entry to a new directory entry ... Creating a link to a directory entry that is itself a directory requires elevated privileges ...
Vuze Release History
... menu item UI
FATX - Technical Design - Directory Table - Directory Entry
... and creation/access time stamps, bytes 0x0C–0x15 of the directory entry were used by other operating systems to store additional metadata, most notably the operating systems of the Digital ... Directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3 filename) Byte Offset Length (bytes ... Also serves as an end marker when DOS scans a directory table ...

Famous quotes containing the words entry and/or directory:

    All mothers need instruction, nurturing, and an understanding mentor after the birth of a baby, but in this age of fast foods, fast tracks, and fast lanes, it doesn’t always happen. While we live in a society that provides recognition for just about every life event—from baptisms to bar mitzvahs, from wedding vows to funeral rites—the entry into parenting seems to be a solo flight, with nothing and no one to mark formally the new mom’s entry into motherhood.
    Sally Placksin (20th century)

    Although then a printer by trade, he listed himself in this early directory as an antiquarian. When he was asked the reason for this he replied that he always thought every town should have at least one antiquarian, and since none appeared for the post, he volunteered.
    —For the State of Iowa, U.S. public relief program (1935-1943)