Exfat File System Specification: 1.1 Design Goals
Exfat File System Specification: 1.1 Design Goals
1 Introduction
The exFAT file system is the successor to FAT32 in the FAT family of file
systems. This specification describes the exFAT file system and provides all the
information necessary for implementing the exFAT file system.
The exFAT file system has three central design goals (see list below).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 2 of 112
The exFAT file system uses 64 bits to describe file size, thereby
enabling applications which depend on very large files. The exFAT
file system also allows for clusters as large as 32MB, effectively
enabling very large storage devices.
In the context of this specification, certain terms (see Table 1) carry specific
meaning for the design and implementation of the exFAT file system.
Term Definition
Shall This specification uses the term “shall” to describe a behavior which
is mandatory.
May This specification uses the term “may” to describe a behavior which
is optional.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 3 of 112
Term Definition
1. Shall initialize to zero and should not use for any purpose
2. Should not interpret, except when computing checksums
3. Shall preserve across operations which modify surrounding
fields or structures
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 4 of 112
INT Interrupt
Fields and structures in this specification have the following qualifiers (see list
below), unless the specification notes otherwise.
1. Are unsigned
2. Use decimal notation to describe values, where not otherwise noted; this
specification uses the post-fix letter "h" to denote hexadecimal numbers
and encloses GUIDs in curly braces
2 Volume Structure
A volume is the set of all file system structures and data space necessary to
store and retrieve user data. All exFAT volumes contain four regions (see Table
3).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 5 of 112
Main Boot
Region
Backup
Boot
Region
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 6 of 112
FAT
Region
1)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 7 of 112
Data
Region
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 8 of 112
SectorsPerClusterShift
fields.
The Backup Boot region is a backup of the Main Boot region. It aids recovery
of the exFAT volume in the event of the Main Boot region being in an
inconsistent state. Except under infrequent circumstances, such as updating
boot-strapping instructions, implementations should not modify the contents
of the Backup Boot region.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 9 of 112
The Main Boot Sector contains code for boot-strapping from an exFAT
volume and fundamental exFAT parameters which describe the volume
structure (see Table 4). BIOS, MBR, or other boot-strapping agents may
inspect this sector and may load and execute any boot-strapping instructions
contained therein.
The Backup Boot Sector is a backup of the Main Boot Sector and has the same
structure (see Table 4). The Backup Boot Sector may aid recovery operations;
however, implementations shall treat the contents of the VolumeFlags and
PercentInUse fields as stale.
Prior to using the contents of either the Main or Backup Boot Sector,
implementations shall verify their contents by validating their respective Boot
Checksum and ensuring all their fields are within their valid value range.
While the initial format operation will initialize the contents of both the Main
and Backup Boot Sectors, implementations may update these sectors (and
shall also update their respective Boot Checksum) as needed. However,
implementations may update either the VolumeFlags or PercentInUse fields
without updating their respective Boot Checksum (the checksum specifically
excludes these two fields).
(byte) (bytes)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 10 of 112
(byte) (bytes)
FileSystemRevision 104 2
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 11 of 112
(byte) (bytes)
This field is
mandatory and
Section 3.1.12
defines its contents.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 12 of 112
(byte) (bytes)
This field is
mandatory and
Section 3.1.19
defines its contents.
The JumpBoot field shall contain the jump instruction for CPUs common in
personal computers, which, when executed, "jumps" the CPU to execute the
boot-strapping instructions in the BootCode field.
The valid value for this field is (in order of low-order byte to high-order byte)
EBh 76h 90h.
The FileSystemName field shall contain the name of the file system on the
volume.
The valid value for this field is, in ASCII characters, "EXFAT ", which includes
three trailing white spaces.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 13 of 112
The MustBeZero field shall directly correspond with the range of bytes the
packed BIOS parameter block consumes on FAT12/16/32 volumes.
The valid value for this field is 0, which helps to prevent FAT12/16/32
implementations from mistakenly mounting an exFAT volume.
The PartitionOffset field shall describe the media-relative sector offset of the
partition which hosts the given exFAT volume. This field aids boot-strapping
from the volume using extended INT 13h on personal computers.
All possible values for this field are valid; however, the value 0 indicates
implementations shall ignore this field.
The VolumeLength field shall describe the size of the given exFAT volume in
sectors.
However, if the size of the Excess Space sub-region is 0, then the value of this
field is ClusterHeapOffset + (232- 11) * 2SectorsPerClusterShift.
The FatOffset field shall describe the volume-relative sector offset of the First
FAT. This field enables implementations to align the First FAT to the
characteristics of the underlying storage media.
• At least 24, which accounts for the sectors the Main Boot and Backup
Boot regions consume
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 14 of 112
The FatLength field shall describe the length, in sectors, of each FAT table (the
volume may contain up to two FATs).
This field may contain a value in excess of its lower bound (as described
above) to enable the Second FAT, if present, to also be aligned to the
characteristics of the underlying storage media. The contents of the space
which exceeds what the FAT itself requires, if any, are undefined.
The ClusterCount field shall describe the number of clusters the Cluster Heap
contains.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 15 of 112
The valid value for this field shall be the lesser of the following:
• 232- 11, which is the maximum number of clusters a FAT can describe
The value of the ClusterCount field determines the minimum size of a FAT. To
avoid extremely large FATs, implementations can control the number of
clusters in the Cluster Heap by increasing the cluster size (via the
SectorsPerClusterShift field). This specification recommends no more than 224-
2 clusters in the Cluster Heap. However, implementations shall be able to
handle volumes with up to 232- 11 clusters in the Cluster Heap.
The FirstClusterOfRootDirectory field shall contain the cluster index of the first
cluster of the root directory. Implementations should make every effort to
place the first cluster of the root directory in the first non-bad cluster after the
clusters the Allocation Bitmap and Up-case Table consume.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 16 of 112
The FileSystemRevision field shall describe the major and minor revision
numbers of the exFAT structures on the given volume.
The high-order byte is the major revision number and the low-order byte is
the minor revision number. For example, if the high-order byte contains the
value 01h and if the low-order byte contains the value 05h, then the
FileSystemRevision field describes the revision number 1.05. Likewise, if the
high-order byte contains the value 0Ah and if the low-order byte contains the
value 0Fh, then the FileSystemRevision field describes the revision number
10.15.
• At least 0 for the low-order byte and 1 for the high-order byte
• At most 99 for the low-order byte and 99 for the high-order byte
The VolumeFlags field shall contain flags which indicate the status of various
file system structures on the exFAT volume (see Table 5).
Implementations shall not include this field when computing its respective
Main Boot or Backup Boot region checksum. When referring to the Backup
Boot Sector, implementations shall treat this field as stale.
(bit) (bits)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 17 of 112
(bit) (bits)
The ActiveFat field shall describe which FAT and Allocation Bitmap are active
(and implementations shall use), as follows:
• 0, which means the First FAT and First Allocation Bitmap are active
• 1, which means the Second FAT and Second Allocation Bitmap are active
and is possible only when the NumberOfFats field contains the value 2
The VolumeDirty field shall describe whether the volume is dirty or not, as
follows:
Implementations should set the value of this field to 1 upon encountering file
system metadata inconsistencies which they do not resolve. If, upon mounting
a volume, the value of this field is 1, only implementations which resolve file
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 18 of 112
system metadata inconsistencies may clear the value of this field to 0. Such
implementations shall only clear the value of this field to 0 after ensuring the
file system is in a consistent state.
• 0, which means the hosting media has not reported failures or any
known failures are already recorded in the FAT as "bad" clusters
• 1, which means the hosting media has reported failures (i.e. has failed
read or write operations)
1. The hosting media fails access attempts to any region in the volume
If, upon mounting a volume, the value of this field is 1, implementations which
scan the entire volume for media failures and record all failures as "bad"
clusters in the FAT (or otherwise resolve media failures) may clear the value of
this field to 0.
The ClearToZero field does not have significant meaning in this specification.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 19 of 112
The BytesPerSectorShift field shall describe the bytes per sector expressed as
log2(N), where N is the number of bytes per sector. For example, for 512 bytes
per sector, the value of this field is 9.
• At least 9 (sector size of 512 bytes), which is the smallest sector possible
for an exFAT volume
• At most 12 (sector size of 4096 bytes), which is the memory page size of
CPUs common in personal computers
The NumberOfFats field shall describe the number of FATs and Allocation
Bitmaps the volume contains.
• 1, which indicates the volume only contains the First FAT and First
Allocation Bitmap
• 2, which indicates the volume contains the First FAT, Second FAT, First
Allocation Bitmap, and Second Allocation Bitmap; this value is only valid
for TexFAT volumes
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 20 of 112
The DriveSelect field shall contain the extended INT 13h drive number, which
aids boot-strapping from this volume using extended INT 13h on personal
computers.
All possible values for this field are valid. Similar fields in previous FAT-based
file systems frequently contained the value 80h.
The PercentInUse field shall describe the percentage of clusters in the Cluster
Heap which are allocated.
Implementations shall change the value of this field to reflect changes in the
allocation of clusters in the Cluster Heap or shall change it to FFh.
Implementations shall not include this field when computing its respective
Main Boot or Backup Boot region checksum. When referring to the Backup
Boot Sector, implementations shall treat this field as stale.
The BootSignature field shall describe whether the intent of a given sector is
for it to be a Boot Sector or not.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 21 of 112
The valid value for this field is AA55h. Any other value in this field invalidates
its respective Boot Sector. Implementations should verify the contents of this
field prior to depending on any other field in its respective Boot Sector.
Each sector of the Main Extended Boot Sectors has the same structure;
however, each sector may hold distinct boot-strapping instructions (see Table
6). Boot-strapping agents, such as the boot-strapping instructions in the Main
Boot Sector, alternate BIOS implementations, or an embedded system's
firmware, may load these sectors and execute the instructions they contain.
The Backup Extended Boot Sectors is a backup of the Main Extended Boot
Sectors and has the same structure (see Table 6).
Prior to executing the instructions of either the Main or Backup Extended Boot
Sectors, implementations should verify their contents by ensuring each
sector's ExtendedBootSignature field contains its prescribed value.
While the initial format operation will initialize the contents of both the Main
and Backup Extended Boot Sectors, implementations may update these
sectors (and shall also update their respective Boot Checksum) as needed.
(byte) (bytes)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 22 of 112
(byte) (bytes)
Section 3.2.2
defines its
contents.
The valid value for this field is AA550000h. Any other value in this field
invalidates its respective Main or Backup Extended Boot Sector.
Implementations should verify the contents of this field prior to depending on
any other field in its respective Extended Boot Sector.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 23 of 112
defines two parameters structures: Null Parameters (see Section 3.3.3) and
Flash Parameters (see Section 3.3.4).
The Backup OEM Parameters is a backup of the Main OEM Parameters and
has the same structure (see Table 7).
Prior to using the contents of either the Main or Backup OEM Parameters,
implementations shall verify their contents by validating their respective Boot
Checksum.
Manufacturers should populate the Main and Backup OEM Parameters with
their own custom parameters structures, if any, and any other parameter
structures. Subsequent format operations shall preserve the contents of the
Main and Backup OEM Parameters.
. . . .
. . . .
. . . .
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 24 of 112
(byte) (bytes)
The ParametersGuid field shall describe a GUID, which determines the layout
of the remainder of the given parameters structure.
All possible values for this field are valid; however, manufacturers should use a
GUID-generating tool, such as GuidGen.exe, to select a GUID when deriving
custom parameters structures from this template.
The Null Parameters structure derives from the Generic Parameters template
(see Section 3.3.2) and shall describe an unused Parameters field (see Table 9).
When creating or updating the OEM Parameters structure, implementations
shall populate unused Parameters fields with the Null Parameters structure.
Also, when creating or updating the OEM Parameters structure,
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 25 of 112
(byte) (bytes)
The Flash Parameter structure derives from the Generic Parameters template
(see Section 3.3.2) and contains parameters for flash media (see Table 10).
Manufacturers of flash-based storage devices may populate a Parameters field
(preferably the Parameters[0] field) with this parameters structure.
Implementations may use the information in the Flash Parameters structure to
optimize access operations during reads/writes and for alignment of file
system structures durning formatting of the media.
(byte) (bytes)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 26 of 112
(byte) (bytes)
All possible values for all Flash Parameters fields, except for the
ParametersGuid field, are valid. However, the value 0 indicates the field is
actually meaningless (implementations shall ignore the given field).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 27 of 112
The EraseBlockSize field shall describe the size, in bytes, of the flash media's
erase block.
The PageSize field shall describe the size, in bytes of the flash media's page.
The SpareSectors field shall describe the number of sectors the flash media
has available for its internal sparing operations.
The RandomAccessTime field shall describe the flash media's average random
access time, in nanoseconds.
The ReadCycle field shall describe the flash media's average read cycle time, in
nanoseconds.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 28 of 112
The WriteCycle field shall describe the average write cycle time, in
nanoseconds.
The Main and Backup Boot Checksums each contain a repeating pattern of
the four-byte checksum of the contents of all other sub-regions in their
respective Boot regions. The checksum calculation shall not include the
VolumeFlags and PercentInUse fields in their respective Boot Sector (see
Figure 1). The repeating pattern of the four-byte checksum fills its respective
Boot Checksum sub-region from the beginning to the end of the sub-region.
Prior to using the contents of any of the other sub-regions in either the Main
or Backup Boot regions, implementations shall verify their contents by
validating their respective Boot Checksum.
While the initial format operation will populate both the Main and Backup
Boot Checksums with the repeating checksum pattern, implementations shall
update these sectors as the contents of the other sectors in their respective
Boot regions change.
C = Copy
UInt32 BootChecksum
(
UCHAR * Sectors, // points to an in-memory copy of the
11 sectors
USHORT BytesPerSector
)
{
UInt32 NumberOfBytes = (UInt32)BytesPerSector * 11;
UInt32 Checksum = 0;
UInt32 Index;
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 29 of 112
return Checksum;
}
The ActiveFat field of the VolumeFlags field describes which FAT is active. Only
the VolumeFlags field in the Main Boot Sector is current. Implementations
shall treat the FAT which is not active as stale. Use of the inactive FAT and
switching between FATs is implementation specific.
A FAT shall describe cluster chains in the Cluster Heap (see Table 11). A cluster
chain is a series of clusters which provides space for recording the contents of
files, directories, and other file system structures. A FAT represents a cluster
chain as a singly-linked list of cluster indices. With the exception of the first
two entries, every entry in a FAT represents exactly one cluster.
(byte) (bytes)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 30 of 112
(byte) (bytes)
. . . .
. . . .
. . . .
ClusterCount + 1 can
never exceed
FFFFFFF6h.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 31 of 112
The FatEntry[0] field shall describe the media type in the first byte (the lowest
order byte) and shall contain FFh in the remaining three bytes.
The FatEntry[1] field only exists due to historical precedence and does not
describe anything of interest.
The valid value for this field is FFFFFFFFh. Implementations shall initialize this
field to its prescribed value and should not use this field for any purpose.
Implementations should not interpret this field and shall preserve its contents
across operations which modify surrounding fields.
Each FatEntry field in this array shall represent a cluster in the Cluster Heap.
FatEntry[2] represents the first cluster in the Cluster Heap and FatEntry
[ClusterCount+1] represents the last cluster in the Cluster Heap.
5 Data Region
The Data region contains the Cluster Heap, which provides managed space for
file system structures, directories, and files.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 32 of 112
The Cluster Heap's structure is very simple (see Table 12); each consecutive
series of sectors describes one cluster, as the SectorsPerClusterShift field
defines. Importantly, the first cluster of the Cluster Heap has index two, which
directly corresponds to the index of FatEntry[2].
(sector) (sectors)
. . . .
. . . .
. . . .
ClusterCount,
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 33 of 112
(sector) (sectors)
ClusterHeapOffset,
and
SectorsPerClusterShift
fields.
Each Cluster field in this array is a series of contiguous sectors, whose size is
defined by the SectorsPerClusterShift field.
6 Directory Structure
The exFAT file system uses a directory tree approach to manage the file
system structures and files which exist in the Cluster Heap. Directories have a
one-to-many relationship between parent and child in the directory tree.
One or more directory entries combine into a directory entry set which
describes something of interest, such as a file system structure, sub-directory,
or file.
(byte) (byte)
. . . .
. . . .
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 34 of 112
(byte) (byte)
. . . .
Each DirectoryEntry field in this array derives from the Generic DirectoryEntry
template (see Section 6.2).
The Generic DirectoryEntry template provides the base definition for directory
entries (see Table 14). All directory entry structures derive from this template
and only Microsoft-defined directory entry structures are valid (exFAT does
not have provisions for manufacturer-defined directory entry structures except
as defined in Section 7.8 and Section 7.9). The ability to interpret the Generic
DirectoryEntry template is mandatory.
(byte) (byte)
FirstCluster 20 4
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 35 of 112
(byte) (byte)
The EntryType field has three modes of usage which the value of the field
defines (see list below).
◦ All subsequent directory entries in the given directory also are end-of-
directory markers
◦ Unused directory entries are only valid outside of directory entry sets
• Between 81h and FFh inclusively, which is a regular directory entry and
the following conditions apply:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 36 of 112
◦ The contents of the EntryType field (see Table 15) determine the
layout of the remainder of the DirectoryEntry structure
◦ This range of values, and only this range of values, are valid inside a
directory entry set
(bit) (bits)
The TypeCode field partially describes the specific type of the given directory
entry. This field, plus the TypeImportance and TypeCategory fields (see
Section 6.2.1.2 and Section 6.2.1.3, respectively) uniquely identify the type of
the given directory entry.
All possible values of this field are valid, unless the TypeImportance and
TypeCategory fields both contain the value 0; in that case, the value 0 is
invalid for this field.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 37 of 112
The TypeImportance field shall describe the importance of the given directory
entry.
• 0, which means the given directory entry is critical (see Section 6.3.1.2.1
and Section 6.4.1.2.1 for critical primary and critical secondary directory
entries, respectively)
• 1, which means the given directory entry is benign (see Section 6.3.1.2.2
and Section 6.4.1.2.2 for benign primary and benign secondary directory
entries, respectively)
The TypeCategory field shall describe the category of the given directory
entry.
• 0, which means the given directory entry is primary (see Section 6.3)
• 1, which means the given directory entry is secondary (see Section 6.4)
The InUse field shall describe whether the given directory entry in use or not.
• 0, which means the given directory entry is not in use; this means the
given structure actually is an unused directory entry
• 1, which means the given directory entry is in use; this means the given
structure is a regular directory entry
The FirstCluster field shall contain the index of the first cluster of an allocation
in the Cluster Heap associated with the given directory entry.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 38 of 112
Structures which derive from this template may redefine both the FirstCluster
and DataLength fields, if a cluster allocation is not compatible with the
derivative structure.
The DataLength field describes the size, in bytes, of the data the associated
cluster allocation contains.
• At least 0; if the FirstCluster field contains the value 0, then this field's
only valid value is 0
Structures which derive from this template may redefine both the FirstCluster
and DataLength fields, if a cluster allocation is not possible for the derivative
structure.
The first directory entry in a directory entry set shall be a primary directory
entry. All subsequent directory entries, if any, in the directory entry set shall be
secondary directory entries (see Section 6.4).
All primary directory entry structures derive from the Generic Primary
DirectoryEntry template (see Table 16), which derives from the Generic
DirectoryEntry template (see Section 6.2).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 39 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1).
The TypeCode field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.1).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 40 of 112
The TypeCategory field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.3).
For this template, the valid value for this field shall be 0.
The InUse field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.4).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 41 of 112
secondary directory entries, along with the given primary directory entry,
comprise the directory entry set.
• At least 0, which means this primary directory entry is the only entry in
the directory entry set
• At most 255, which means the next 255 directory entries and this primary
directory entry comprise the directory entry set
Critical primary directory entry structures which derive from this template may
redefine both the SecondaryCount and SetChecksum fields.
The SetChecksum field shall contain the checksum of all directory entries in
the given directory entry set. However, the checksum excludes this field (see
Figure 2). Implementations shall verify the contents of this field are valid prior
to using any other directory entry in the given directory entry set.
Critical primary directory entry structures which derive from this template may
redefine both the SecondaryCount and SetChecksum fields.
C = Copy
UInt16 EntrySetChecksum
(
UCHAR * Entries, // points to an in-memory copy of the
directory entry set
UCHAR SecondaryCount
)
{
UInt16 NumberOfBytes = ((UInt16)SecondaryCount + 1) * 32;
UInt16 Checksum = 0;
UInt16 Index;
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 42 of 112
Critical primary directory entry structures which derive from this template may
redefine this field.
(bit) (bits)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 43 of 112
The NoFatChain field shall indicate whether or not the active FAT describes
the given allocation's cluster chain.
• 0, which means the corresponding FAT entries for the allocation's cluster
chain are valid and implementations shall interpret them; if the
AllocationPossible field contains the value 0, or if the AllocationPossible
field contains the value 1 and the FirstCluster field contains the value 0,
then this field's only valid value is 0
If critical primary directory entry structures which derive from this template
redefine the GeneralPrimaryFlags field, then the corresponding FAT entries for
any associated allocation's cluster chain are valid.
The FirstCluster field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.2).
If the NoFatChain bit is 1 then FirstCluster must point to a valid cluster in the
cluster heap.
Critical primary directory entry structures which derive from this template may
redefine the FirstCluster and DataLength fields. Other structures which derive
from this template may redefine the FirstCluster and DataLength fields only if
the AllocationPossible field contains the value 0.
The DataLength field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.3).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 44 of 112
If the NoFatChain bit is 1 then DataLength must not be zero. If the FirstCluster
field is zero, then DataLength must also be zero.
Critical primary directory entry structures which derive from this template may
redefine the FirstCluster and DataLength fields. Other structures which derive
from this template may redefine the FirstCluster and DataLength fields only if
the AllocationPossible field contains the value 0.
All secondary directory entry structures derive from the Generic Secondary
DirectoryEntry template (see Table 18), which derives from the Generic
DirectoryEntry template (see Section 6.2).
(byte) (byte)
FirstCluster 20 4
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 45 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1)
The TypeCode field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.1).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 46 of 112
The TypeCategory field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.3).
The InUse field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.1.4).
(bit) (bits)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 47 of 112
The AllocationPossible field shall have the same definition as the same-named
field in the Generic Primary DirectoryEntry template (see Section 6.3.4.1).
The NoFatChain field shall have the same definition as the same-named field
in the Generic Primary DirectoryEntry template (see Section 6.3.4.2).
The FirstCluster field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.2).
If the NoFatChain bit is 1 then FirstCluster must point to a valid cluster in the
cluster heap.
The DataLength field shall conform to the definition provided in the Generic
DirectoryEntry template (see Section 6.2.3).
If the NoFatChain bit is 1 then DataLength must not be zero. If the FirstCluster
field is zero, then DataLength must also be zero.
• Critical primary
• Benign primary
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 48 of 112
• Critical secondary
• Benign secondary
In the exFAT file system, a FAT does not describe the allocation state of
clusters; rather, an Allocation Bitmap does. Allocation Bitmaps exist in the
Cluster Heap (see Section 7.1.5) and have corresponding critical primary
directory entries in the root directory (see Table 20).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 49 of 112
The EntryType field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1).
The TypeCode field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.1).
For an Allocation Bitmap directory entry, the valid value for this field is 1.
For an Allocation Bitmap directory entry, the valid value for this field is 0.
The TypeCategory field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.3).
The InUse field shall conform to the definition provided in the Generic Primary
DirectoryEntry template (see Section 6.3.1.4).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 50 of 112
(bit) (bits)
The BitmapIdentifier field shall indicate which Allocation Bitmap the given
directory entry describes. Implementations shall use the First Allocation
Bitmap in conjunction with the First FAT and shall use the Second Allocation
Bitmap in conjunction with the Second FAT. The ActiveFat field describes
which FAT and Allocation Bitmap are active.
• 0, which means the given directory entry describes the First Allocation
Bitmap
• 1, which means the given directory entry describes the Second Allocation
Bitmap and is possible only when NumberOfFats contains the value 2
The FirstCluster field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.5).
This field contains the index of the first cluster of the cluster chain, as the FAT
describes, which hosts the Allocation Bitmap.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 51 of 112
The DataCluster field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.6).
An Allocation Bitmap records the allocation state of the clusters in the Cluster
Heap. Each bit in an Allocation Bitmap indicates whether its corresponding
cluster is available for allocation or not.
(bit) (bits)
. . . .
. . . .
. . . .
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 52 of 112
(bit) (bits)
Each BitmapEntry field in this array represents a cluster in the Cluster Heap.
BitmapEntry[2] represents the first cluster in the Cluster Heap and BitmapEntry
[ClusterCount+1] represents the last cluster in the Cluster Heap.
Due to the relationship between the Up-case Table and file names,
implementations should not modify the Up-case Table, except as a result of
format operations.
(byte) (byte)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 53 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1).
The TypeCode field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.1).
For the Up-case Table directory entry, the valid value for this field is 2.
For the Up-case Table directory entry, the valid value for this field is 0.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 54 of 112
The TypeCategory field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.3).
The InUse field shall conform to the definition provided in the Generic Primary
DirectoryEntry template (see Section 6.3.1.4).
The TableChecksum field contains the checksum of the Up-case Table (which
the FirstCluster and DataLength fields describe). Implementations shall verify
the contents of this field are valid prior to using the Up-case Table.
C = Copy
UInt32 TableChecksum
(
UCHAR * Table, // points to an in-memory copy of the up-
case table
UInt64 DataLength
)
{
UInt32 Checksum = 0;
UInt64 Index;
return Checksum;
}
The FirstCluster field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.5).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 55 of 112
This field contains the index of the first cluster of the cluster chain, as the FAT
describes, which hosts the Up-case Table.
The DataCluster field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.6).
The first 128 Unicode characters have mandatory mappings (see Table 24). An
up-case table which has any other character mapping for any of the first 128
Unicode characters is invalid.
Table Table
Index Entries
+0 +1 +2 +3 +4 +5 +6
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 56 of 112
Table Table
Index Entries
(Note: entries with non-identity up-case mappings are in bold)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 57 of 112
identity mappings with the value FFFFh followed with the number of identity
mappings.
For example, an implementation may represent the first 100 (64h) character
mappings with the following eight entries of a compressed up-case table:
The first two entries indicate the first 97 (61h) characters (from 0000h to
0060h) have identity mappings. The subsequent characters, 0061h through
0063h, map to characters 0041h through 0043h, respectively.
Raw Compressed
Offset Table
Entries
+0 +1 +2 +3 +4 +5
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 58 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 59 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 60 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 61 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 62 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 63 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 64 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 65 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 66 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 67 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 68 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 69 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 70 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 71 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 72 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 73 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 74 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 75 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 76 of 112
Raw Compressed
Offset Table
Entries
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 77 of 112
Raw Compressed
Offset Table
Entries
The Volume Label is a Unicode string which enables end users to distinguish
their storage volumes. In the exFAT file system, the Volume Label exists as a
critical primary directory entry in the root directory (see Table 26). The valid
number of Volume Label directory entries ranges from 0 to 1.
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1).
The TypeCode field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.1).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 78 of 112
For the Volume Label directory entry, the valid value for this field is 3.
For the Volume Label directory entry, the valid value for this field is 0.
The TypeCategory field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.3).
The InUse field shall conform to the definition provided in the Generic Primary
DirectoryEntry template (see Section 6.3.1.4).
The CharacterCount field shall contain the length of the Unicode string the
VolumeLabel field contains.
The VolumeLabel field shall contain a Unicode string, which is the user-
friendly name of the volume. The VolumeLabel field has the same set of
invalid characters as the FileName field of the File Name directory entry (see
Section 7.7.3).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 79 of 112
File directory entries describe files and directories. They are critical primary
directory entries and any directory may contain zero or more File directory
entries (see Table 27). For a File directory entry to be valid, exactly one Stream
Extension directory entry and at least one File Name directory entry must
immediately follow the File directory entry (see Section 7.6 and Section 7.7,
respectively).
(byte) (byte)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 80 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1).
The TypeCode field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.1).
For a File directory entry, the valid value for this field is 5.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 81 of 112
For a File directory entry, the valid value for this field is 0.
The TypeCategory field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.3).
The InUse field shall conform to the definition provided in the Generic Primary
DirectoryEntry template (see Section 6.3.1.4).
The SetChecksum field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.3).
System 2 1
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 82 of 112
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 83 of 112
1. After modifying the contents of any of the clusters associated with the
given Stream Extension directory entry (except for contents which exist
beyond the point the ValidDataLength field describes)
The LastAccessedTimestamp field shall describe the local date and time the
contents of any of the clusters associated with the given Stream Extension
directory entry were last accessed. The LastAccessedUtcOffset field describes
the offset of local date and time from UTC. Implementations shall update
these fields:
1. After modifying the contents of any of the clusters associated with the
given Stream Extension directory entry (except for contents which exist
beyond the ValidDataLength)
Implementations should update these fields after reading the contents of any
of the clusters associated with the given Stream Extension directory entry.
These fields shall conform to the definitions of the Timestamp and UtcOffset
fields (see Section 7.4.8 and Section 7.4.10, respectively).
Timestamp fields describe both local date and time, down to a two-second
resolution (see Table 29).
(bit) (bits)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 84 of 112
(bit) (bits)
The DoubleSeconds field shall describe the seconds portion of the Timestamp
field, in two-second multiples.
The Minute field shall describe the minutes portion of the Timestamp field.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 85 of 112
The Hour field shall describe the hours portion of the Timestamp field.
The Day field shall describe the day portion of the Timestamp field.
• The last day of the given month (the given month defines the number of
valid days)
The Month field shall describe the month portion of the Timestamp field.
The Year field shall describe the year portion of the Timestamp field, relative
to the year 1980. This field represents the year 1980 with the value 0 and the
year 2107 with the value 127.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 86 of 112
UtcOffset fields (see Table 30) shall describe the offset from UTC to the local
date and time their corresponding Timestamp and 10msIncrement fields
describe. The offset from UTC to the local date and time includes the effects
of time zones and other date-time adjustments, such as daylight saving and
regional summer time changes.
(bit) (bits)
The OffsetFromUtc field shall describe the offset from UTC of the local date
and time the related Timestamp and 10msIncrement fields contains. This field
describes the offset from UTC in 15 minute intervals (see Table 31).
. . .
. . .
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 87 of 112
. . .
. . .
. . .
. . .
As the table above indicates, all possible values for this field are valid.
However, implementations should only record the value 00h for this field
when:
1. Local date and time are actually the same as UTC, in which case the value
of the OffsetValid field shall be 1
2. Local date and time are not known, in which case the value of the
OffsetValid field shall be 1 and implementations shall consider UTC to be
local date and time
3. UTC is not known, in which case the value of the OffsetValid field shall
be 0
If the local date and time offset from UTC happens to not be a multiple of 15
minute intervals, then implementations shall record 00h in the OffsetFromUtc
field and shall consider UTC to be local date and time.
The OffsetValid field shall describe whether the contents of the OffsetFromUtc
field are valid or not, as follows:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 88 of 112
Implementations should only set this field to the value 0 when UTC is not
available for computing the value of the OffsetFromUtc field. If this field
contains the value 0, then implementations shall treat the Timestamp and
10msIncrement fields as having the same UTC offset as the current local date
and time.
(byte) (byte)
Reserved 22 10
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 89 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1).
The TypeCode field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.1).
For the Volume GUID directory entry, the valid value for this field is 0.
For the Volume GUID directory entry, the valid value for this field is 1.
The TypeCategory field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.1.3).
The InUse field shall conform to the definition provided in the Generic Primary
DirectoryEntry template (see Section 6.3.1.4).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 90 of 112
For the Volume GUID directory entry, the valid value for this field is 0.
The SetChecksum field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.3).
For the Volume GUID directory entry, the valid value for this field is 0.
The NoFatChain field shall conform to the definition provided in the Generic
Primary DirectoryEntry template (see Section 6.3.4.2).
The VolumeGuid field shall contain a GUID which uniquely identifies the given
volume.
All possible values for this field are valid, except the null GUID, which is
{00000000-0000-0000-0000-000000000000}.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 91 of 112
(byte) (byte)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 92 of 112
The EntryType field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1).
The TypeCode field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.1).
For the Stream Extension directory entry, the valid value for this field is 0.
For the Stream Extension directory entry, the valid value for this field is 0.
The TypeCategory field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.3).
The InUse field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.4).
For the Stream Extension directory entry, the valid value for this field is 1.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 93 of 112
The NoFatChain field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.2.2).
The NameLength field shall contain the length of the Unicode string the
subsequent File Name directory entries (see Section 7.7) collectively contain.
The value of the NameLength field also affects the number File Name
Directory Entries (see Section 7.7).
The NameHash field shall contain a 2-byte hash (see Figure 4) of the up-cased
file name. This enables implementations to perform a quick comparison when
searching for a file by name. Importantly, the NameHash provides a sure
verification of a mismatch. Implementations shall verify all NameHash matches
with a comparison of the up-cased file name.
C = Copy
UInt16 NameHash
(
WCHAR * FileName, // points to an in-memory copy of the up-
cased file name
UCHAR NameLength
)
{
UCHAR * Buffer = (UCHAR *)FileName;
UInt16 NumberOfBytes = (UInt16)NameLength * 2;
UInt16 Hash = 0;
UInt16 Index;
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 94 of 112
The ValidDataLength field shall describe how far into the data stream user
data has been written. Implementations shall update this field as they write
data further out into the data stream. On the storage media, the data between
the valid data length and the data length of the data stream is undefined.
Implementations shall return zeroes for read operations beyond the valid data
length.
If the corresponding File directory entry describes a directory, then the only
valid value for this field is equal to the value of the DataLength field.
Otherwise, the range of valid values for this field shall be:
• At least 0, which means no user data has been written out to the data
stream
• At most DataLength, which means user data has been written out to the
entire length of the data stream
The FirstCluster field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.3).
This field shall contain the index of the first cluster of the data stream, which
hosts the user data.
The DataLength field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.4).
If the corresponding File directory entry describes a directory, then the valid
value for this field is the entire size of the associated allocation, in bytes, which
may be 0. Further, for directories, the maximum value for this field is 256MB.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 95 of 112
File Name directory entries are critical secondary directory entries in File
directory entry sets (see Table 34). The valid number of File Name directory
entries in a File directory entry set is NameLength / 15, rounded up to the
nearest integer. Further, File Name directory entries are valid only if they
immediately follow the Stream Extension directory entry as a consecutive
series. File Name directory entries combine to form the file name for the File
directory entry set.
All children of a given directory entry shall have unique File Name Directory
Entry Sets. That is to say there can be no duplicate file or directory names
after up-casing within any one directory.
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1).
The TypeCode field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.1).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 96 of 112
For the Stream Extension directory entry, the valid value for this field is 1.
For the Stream Extension directory entry, the valid value for this field is 0.
The TypeCategory field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.3).
The InUse field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.4).
For the Stream Extension directory entry, the valid value for this field is 0.
The NoFatChain field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.2.2).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 97 of 112
The FileName field shall contain a Unicode string, which is a portion of the file
name. In the order File Name directory entries exist in a File directory entry
set, FileName fields concatenate to form the file name for the File directory
entry set. Given the length of the FileName field, 15 characters, and the
maximum number of File Name directory entries, 17, the maximum length of
the final, concatenated file name is 255.
The concatenated file name has the same set of illegal characters as other
FAT-based file systems (see Table 35). Implementations should set the unused
characters of FileName fields to the value 0000h.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 98 of 112
The file names "." and ".." have the special meaning of "this directory" and
"containing directory", respectively. Implementations shall not record either of
these reserved file names in the FileName field. However, implementations
may generate these two file names in directory listings to refer to the
directory being listed and the containing directory.
Implementations may wish to restrict file and directory names to just the ASCII
character set. If so they should limit their character use to the range of valid
characters in the first 128 Unicode entries. They must still store file and
directory names in Unicode on the volume and translate to/from
ASCII/Unicode when interfacing with the user.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 99 of 112
VendorGuid field (see Table 36). Unique directory entries effectively enable
vendors to extend the exFAT file system. Vendors may define the contents of
the VendorDefined field (see Table 36). Vendor implementations may
maintain the contents of the VendorDefined field and may provide vendor-
specific functionality.
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1).
The TypeCode field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.1).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 100 of 112
For the Vendor Extension directory entry, the valid value for this field is 0.
For the Vendor Extension directory entry, the valid value for this field is 1.
The TypeCategory field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.3).
The InUse field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.4).
For the Vendor Extension directory entry, the valid value for this field is 0.
The NoFatChain field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.2.2).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 101 of 112
The VendorGuid field shall contain a GUID which uniquely identifies the given
Vendor Extension.
All possible values for this field are valid, except the null GUID, which is
{00000000-0000-0000-0000-000000000000}. However, vendors should use a
GUID-generating tool, such as GuidGen.exe, to select a GUID when defining
their extensions.
(byte) (byte)
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 102 of 112
(byte) (byte)
The EntryType field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1).
The TypeCode field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.1).
For the Vendor Allocation directory entry, the valid value for this field is 1.
For the Vendor Allocation directory entry, the valid value for this field is 1.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 103 of 112
The TypeCategory field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.3).
The InUse field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.1.4).
For the Vendor Allocation directory entry, the valid value for this field is 1.
The NoFatChain field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.2.2).
The VendorGuid field shall contain a GUID which uniquely identifies the given
Vendor Allocation.
All possible values for this field are valid, except the null GUID, which is
{00000000-0000-0000-0000-000000000000}. However, vendors should use a
GUID-generating tool, such as GuidGen.exe, to select a GUID when defining
their extensions.
The value of this field determines the vendor-specific structure of the contents
of the associated clusters, if any exist.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 104 of 112
The FirstCluster field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.3).
The DataLength field shall conform to the definition provided in the Generic
Secondary DirectoryEntry template (see Section 6.4.4).
This specification, exFAT Revision 1.00 File System Basic Specification, does
not define the TexFAT Padding directory entry. However, its type code is 1 and
its type importance is 1. Implementations of this specification shall treat
TexFAT Padding directory entries the same as any other unrecognized benign
primary directory entries, implementations shall not move TexFAT Padding
directory entries.
8 Implementation Notes
5. Clear the value of the VolumeDirty field to 0, if its value prior to the first
step was 0
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 105 of 112
5. Clear the value of the VolumeDirty field to 0, if its value prior to the first
step was 0
Future exFAT specifications of the same major revision number, 1, and minor
revision number higher than 0, may define new benign primary, critical
secondary, and benign secondary directory entries. Only exFAT specifications
of a higher major revision number may define new critical primary directory
entries. Implementations of this specification, exFAT Revision 1.00 File System
Basic Specification, should be able to mount and access any exFAT volume of
major revision number 1 and any minor revision number. This presents
scenarios in which an implementation may encounter directory entries which
it does not recognize. The following describe implications of these scenarios:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 106 of 112
The BytesPerSectorShift field defines the lower and upper sector size limits
(which evaluates to lower limit: 512 bytes; upper limit: 4,096 bytes).
The SectorsPerClusterShift field defines the lower and upper cluster size limits
(lower limit: 1 sector; upper limit: 25 -- BytesPerSectorShift sectors, which
evaluates to 32MB).
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 107 of 112
The Cluster Heap shall contain at least enough space to host the following
basic file system structures: the root directory, all Allocation Bitmaps, and the
Up-case Table.
The lower Cluster Heap size limit is a function of the lower size limit of each of
the basic file system structures which reside in the Cluster Heap. Even given
the smallest possible cluster (512 bytes), each of the basic file system
structures needs no more than one cluster. Therefore, the lower limit is: 2 +
NumberOfFats clusters, which evaluates to either 3 or 4 clusters, depending
on the value the NumberOfFats field.
The upper Cluster Heap size limit is a simple function of the maximum
possible number of clusters, which the ClusterCount field defines (upper
limit: 232- 11 clusters). Regardless of the cluster size, such a cluster heap has
enough space to at least host the basic file system structures.
The VolumeLength field defines the lower and upper volume size limits (lower
limit: 220/ 2BytesPerSectorShiftsectors, which evaluates to 1MB; upper limit: 264- 1
sectors, which, given the largest possible sector size, evaluates to
approximately 64ZB). However, this specification recommends no more than
224- 2 clusters in the Cluster Heap (see Section 3.1.9). Therefore, the
recommended upper limit of a volume is: ClusterHeapOffset + (224- 2) *
2SectorsPerClusterShift. Given the largest possible cluster size, 32MB, and assuming
ClusterHeapOffset is 96MB (enough space for the Main and Backup Boot
regions and only the First FAT), the recommended upper limit of a volume
evaluates to approximately 512TB.
The DataLength field of the Stream Extension directory entry defines the lower
and upper directory size limits (lower limit: 0 bytes; upper limit: 256MB).
This means a directory may host up to 8,388,608 directory entries (each
directory entry consumes 32 bytes). Given the smallest possible File directory
entry set, three directory entries, a directory may host up to 2,796,202 files.
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 108 of 112
10 Appendix
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 109 of 112
Section 2,
Volume Structure
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 110 of 112
08- Second release of the Basic Specification, which includes the following
Jun- changes:
2008
Addition of Section 11,
Documentation Change History
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 111 of 112
01- Third release of the Basic Specification, which includes the following
Oct- changes:
2008
Addition of SHALL, SHOULD and MAY to field explanations
Clarified the restriction that only Microsoft may define the layout of
Directory Entries in Section 6.2
01- Fourth release of the Basic Specification, which includes the following
Jan- changes:
2009
Removed references to Windows CE Access Control entries
02- Fifth release of the Basic Specification, which includes the following
Sep- changes:
2009
Document formatting changes to allow better PDF conversion
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020
exFAT file system specification - Win32 apps | Microsoft Docs Page 112 of 112
24- Sixth release of the Basic Specification, which includes the following
Feb- changes:
2010
Amended incorrect statement: “FirstCluster Field shall be zero if the
DataLength is zero and NoFatChain is set” in Section 6.3.5 and
Section 6.4.3 to “If the NoFatChain bit is 1 then FirstCluster must
point to a valid cluster in the cluster heap“ to clarify that there must
be valid allocation if the NoFatChain bit is set.
Added “If the NoFatChain bit is 1 then DataLength must not be zero.
If the FirstCluster field is zero, then DataLength must also be zero” to
Section 6.3.6 and Section 6.4.4 to clarify that there must be valid
allocation if the NoFatChain bit is set.
26- Seventh release of the Basic Specification, which includes the following
Aug- changes:
2019
Updated legal terms pertaining to the specification, including:
Yes No
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification 5/11/2020