What is fat32 file system

Between 0 and inclusively, which is the percentage of allocated clusters in the Cluster Heap, rounded down to the nearest integer. Exactly FFh, which indicates the percentage of allocated clusters in the Cluster Heap is not available.

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. The BootCode field shall contain boot-strapping instructions.

Implementations may populate this field with the CPU instructions necessary for boot-strapping a computer system. Implementations which don't provide boot-strapping instructions shall initialize each byte in this field to F4h the halt instruction for CPUs common in personal computers as part of their format operation.

The BootSignature field shall describe whether the intent of a given sector is for it to be a Boot Sector or not. 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. 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. This field is mandatory and Section 3. The ExtendedBootCode field shall contain boot-strapping instructions.

Implementations which don't provide boot-strapping instructions shall initialize each byte in this field to 00h as part of their format operation. The ExtendedBootSignature field shall describe whether the intent of given sector is for it to be an Extended Boot Sector or not. The valid value for this field is AAh. Implementations should verify the contents of this field prior to depending on any other field in its respective Extended Boot Sector. The Main OEM Parameters sub-region contains ten parameters structures which may contain manufacturer-specific information see Table 7.

Each of the ten parameters structures derives from the Generic Parameters template see Section 3. Manufacturers may derive their own custom parameters structures from the Generic Parameters template. This specification itself defines two parameters structures: Null Parameters see Section 3. 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. Each Parameters field in this array contains a parameters structure, which derives from the Generic Parameters template see Section 3.

Any unused Parameters field shall be described as containing a Null Parameters structure see Section 3. The Generic Parameters template provides the base definition of a parameters structure see Table 8. All parameters structures derive from this template. Support for this Generic Parameters template is mandatory. 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. 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, implementations should consolidate Null Parameters structures at the end of the array, thereby leaving all other Parameters structures at the beginning of the OEM Parameters structure.

The ParametersGuid field shall conform to the definition provided by the Generic Parameters template see Section 3. Manufacturers of flash-based storage devices may populate a Parameters field preferably the Parameters[0] field with this parameters structure. 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.

The ParametersGuid field shall conform to the definition provided in the Generic Parameters template see Section 3. 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 ProgrammingTime field shall describe the flash media's average programming 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 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.

The valid values for the NumberOfFats field are 1 and 2. Implementations shall treat the FAT which is not active as stale. 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.

This field is mandatory and Section 4. 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. 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. The Data region contains the Cluster Heap, which provides managed space for file system structures, directories, and files. 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].

This field is mandatory and Section 5. Each Cluster field in this array is a series of contiguous sectors, whose size is defined by the SectorsPerClusterShift field. 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. The directory to which the FirstClusterOfRootDirectory field refers is the root of the directory tree. All other directories descend from the root directory in a singly-linked fashion.

Each directory consists of a series of directory entries see Table 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. This field is mandatory and Section 6. N, the number of DirectoryEntry fields, is the size, in bytes, of the cluster chain which contains the given directory, divided by the size of a DirectoryEntry field, 32 bytes.

The Generic DirectoryEntry template provides the base definition for directory entries see Table 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.

The ability to interpret the Generic DirectoryEntry template is mandatory. The EntryType field has three modes of usage which the value of the field defines see list below.

Between 01h and 7Fh inclusively, which is an unused-directory-entry marker and the following conditions apply:. This range of values corresponds to the InUse field see Section 6.

Between 81h and FFh inclusively, which is a regular directory entry and the following conditions apply:. The contents of the EntryType field see Table 15 determine the layout of the remainder of the DirectoryEntry structure. This range of values directly corresponds to the InUse field see Section 6. To prevent modifications to the InUse field see Section 6. The TypeCode field partially describes the specific 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.

The FirstCluster field shall contain the index of the first cluster of an allocation in the Cluster Heap associated with the given directory entry. 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.

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. The TypeImportance field shall conform to the definition provided in the Generic DirectoryEntry template see Section 6. Critical primary directory entries contain information which is critical to the proper management of an exFAT volume. Only the root directory contains critical primary directory entries File directory entries are an exception, see Section 7.

The definition of critical primary directory entries correlates to the major exFAT revision number. Implementations shall support all critical primary directory entries and shall only record the critical primary directory entry structures this specification defines. Benign primary directory entries contain additional information which may be useful for managing an exFAT volume. Any directory may contain benign primary directory entries.

The definition of benign primary directory entries correlates to the minor exFAT revision number. Support for any benign primary directory entry this specification, or any subsequent specification, defines is optional.

An unrecognized benign primary directory entry renders the entire directory entry set as unrecognized beyond the definition of the applicable directory entry templates. The SecondaryCount field shall describe the number of secondary directory entries which immediately follow the given primary directory entry. These 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 , which means the next 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. The GeneralPrimaryFlags field contains flags see Table Critical primary directory entry structures which derive from this template may redefine this field.

The AllocationPossible field shall describe whether or not an allocation in the Cluster Heap is possible for the given directory entry. 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.

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. If the FirstCluster field is zero, then DataLength must also be zero.

The central purpose of secondary directory entries is to provide additional information about a directory entry set. The ability to interpret the Generic Secondary DirectoryEntry template is mandatory. The definition of both critical and benign secondary directory entries correlates to the minor exFAT revision number.

Support for any critical or benign secondary directory entry this specification, or subsequent specifications, defines is optional. 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. Critical secondary directory entries contain information which is critical to the proper management of its containing directory entry set.

While support for any specific critical secondary directory entry is optional, an unrecognized critical directory entry renders the entire directory entry set as unrecognized beyond the definition of the applicable directory entry templates. However, if a directory entry set contains at least one critical secondary directory entry which an implementation does not recognize, then the implementation shall at most interpret the templates of the directory entries in the directory entry set and not the data any allocation associated with any directory entry in the directory entry set contains File directory entries are an exception, see Section 7.

Benign secondary directory entries contain additional information which may be useful for managing its containing directory entry set. Support for any specific benign secondary directory entry is optional. Unrecognized benign secondary directory entries do not render the entire directory entry set as unrecognized. The GeneralSecondaryFlags field contains flags see Table The AllocationPossible field shall have the same definition as the same-named field in the Generic Primary DirectoryEntry template see Section 6.

Allocation Bitmap Section 7. Up-case Table Section 7. Volume Label Section 7. Stream Extension Section 7. File Name Section 7. Vendor Extension Section 7. Vendor Allocation Section 7. Allocation Bitmaps exist in the Cluster Heap see Section 7. The NumberOfFats field determines the number of valid Allocation Bitmap directory entries in the root directory.

If the NumberOfFats field contains the value 1, then the only valid number of Allocation Bitmap directory entries is 1.

Further, the one Allocation Bitmap directory entry is only valid if it describes the First Allocation Bitmap see Section 7. If the NumberOfFats field contains the value 2, then the only valid number of Allocation Bitmap directory entries is 2. Further, the two Allocation Bitmap directory entries are only valid if one describes the First Allocation Bitmap and the other describes the Second Allocation Bitmap. The BitmapFlags field contains flags see Table The BitmapIdentifier field shall indicate which Allocation Bitmap the given directory entry describes.

This field contains the index of the first cluster of the cluster chain, as the FAT describes, which hosts the Allocation Bitmap. 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. An Allocation Bitmap represents clusters from lowest to highest index see Table For historical reasons, the first cluster has index 2.

Note: the first bit in the bitmap is the lowest-order bit of the first byte. This field is mandatory and Section 7. Each BitmapEntry field in this array represents a cluster in the Cluster Heap. The Up-case Table defines the conversion from lower-case to upper-case characters. This is important due to the File Name directory entry see Section 7. The valid number of Up-case Table directory entries is 1. 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.

Implementations shall verify the contents of this field are valid prior to using the Up-case Table. This field contains the index of the first cluster of the cluster chain, as the FAT describes, which hosts the Up-case Table.

An up-case table is a series of Unicode character mappings. A character mapping consists of a 2-byte field, with the index of the field in the up-case table representing the Unicode character to be up-cased, and the 2-byte field representing the up-cased Unicode character.

The first Unicode characters have mandatory mappings see Table An up-case table which has any other character mapping for any of the first Unicode characters is invalid. Implementations which only support characters from the mandatory mapping range may ignore the mappings of the rest of the up-case table. Such implementations shall only use characters from the mandatory mapping range when creating or renaming files via the File Name directory entry, see Section 7.

When up-casing existing file names, such implementations shall not up-case characters from the non-mandatory mapping range, but shall leave them intact in the resulting up-cased file name this is a partial up-casing.

When comparing file names, such implementations shall treat file names which differ from the name under comparison only by Unicode characters from the non-mandatory mapping range as equivalent. While such file names are only potentially equivalent, such implementations cannot ensure the fully up-cased file name does not collide with the name under comparison.

Upon formatting a volume, implementations may generate an up-case table in a compressed format using identity-mapping compression, since a large portion of the Unicode character space has no concept of case which means the "lower-case" and "upper-case" characters are equivalent. Implementations compress an up-case table by representing a series of identity mappings with the value FFFFh followed with the number of identity mappings.

For example, an implementation may represent the first 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 h to h have identity mappings. The subsequent characters, h through h, map to characters h through h, respectively. The ability to provide a compressed up-case table upon formatting a volume is optional.

However, the ability to interpret both an uncompressed and a compressed up-case table is mandatory. The value of the TableChecksum field always conforms to how the up-case table exists on the volume, which may be in either compressed or uncompressed format. When formatting a volume, implementations should record the recommended up-case table in compressed format see Table 25 , for which the value of the TableChecksum field is ED30Dh.

If an implementation defines its own up-case table, either compressed or uncompressed, then that table shall cover the complete Unicode character range from character codes h to FFFFh inclusive. 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 The valid number of Volume Label directory entries ranges from 0 to 1.

The CharacterCount field shall contain the length of the Unicode string the VolumeLabel field contains. At least 0, which means the Unicode string is 0 characters long which is the equivalent of no volume label. The VolumeLabel field shall contain a Unicode string, which is the user-friendly name of the volume. 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 The data width for FAT32 amounts to 32 bits — hence the 32 in its name instead of the 16 bit of the predecessor system. The data width for the current standard file system, NTFS, is 64 bits. However, these values are only an internal specification within the file system and have nothing to do with the bit and bit distinctions between operating systems or processor architecture.

The number of addressable clusters in the FAT32 file system is ,, These small data storage media are practically unusable today in times of larger multimedia data volumes. Units like kibibytes KiB , mebibytes MiB or gibibytes GiB are often used in connection with storage sizes or in the scientific literature.

A kibibyte is exactly 1, bytes, while a kilobyte is only 1, bytes. FAT32 still plays a role on mobile storage media like USB sticks, memory cards, and external hard drives. In some instances, it can be essential for old and new devices to exchange data, for example. However, FAT32 is no longer used on modern, internal Windows hard drives. FAT32 will no longer be the measure of all things in the future as a cross-platform standard ; exFAT, the successor of FAT32, offers more options and larger storage space.

After all, the file sizes and data quantities involved did not approach these limits for quite some time. FAT32 can be used both on various hard drive sizes e. The greatest strength of FAT32 lies in its compatibility. Thanks to FAT32, smooth exchanges of limited amounts of data between otherwise incompatible systems like Windows and macOS continue to work well. FAT32 is also relevant as a format for the cross-platform transmission of data between Windows operating systems and non-Windows operating systems e.

Linux distributions or macOS. But these applications will gradually decline as ever-faster and ever-larger flash storage media emerge. The successor exFAT is now being increasingly used. Because fewer security mechanisms are present in the FAT structure, FAT32 data media should never be the sole storage location for important files.

In the FAT32 file system, the maximum file size is only around 4 gigabytes. Best Tech Gifts for Kids Aged Awesome PC Accessories. Best Linux Laptops. Best Bluetooth Trackers. Best eReaders. Best Gaming Monitors. Best Android Phones. Browse All News Articles.

Prey Predator Prequel Hulu. Window 11 SE Downgrade. Disney Plu TikTok. Windows 11 Default Browser Block. Teams in Windows 11 Taskbar. Smart TVs Ads. Team Comes to Workplace by Meta. Block People Spotify. Verizon Selling PS5. Windows 11 SE Explained. Find Downloaded Files on an iPhone. Use Your iPhone as a Webcam. Hide Private Photos on iPhone. Take Screenshot by Tapping Back of iPhone. Should You Upgrade to Windows 11?

Browse All Windows Articles. Copy and Paste Between Android and Windows. Protect Windows 10 From Internet Explorer. Mozilla Fights Double Standard.