FAT Filesystems

The File Allocation Table (FAT) family began on small Microsoft systems and became the interchange format for DOS and IBM PC media. Simple data structures made FAT practical in boot firmware and constrained operating systems. The same design omits journaling, ownership, and transaction semantics, so interoperability rather than failure isolation explains its continued use.

Volume Layout #

A FAT volume consists of regions measured in logical sectors:

1. The reserved region starts with the volume boot sector and its BIOS Parameter Block (BPB). FAT32 can also place an FSInfo sector and commonly a backup boot sector here.
2. One or more FAT copies contain fixed-width allocation entries. Two copies are conventional, although the BPB states the actual count.
3. The root directory region has a fixed location and entry count on FAT12 and FAT16.
4. The data region contains numbered clusters. On FAT32, the root directory is an ordinary cluster chain in this region rather than a fixed region.

The BPB supplies bytes per sector, sectors per cluster, reserved-sector count, FAT count, total sectors, and FAT size. A reader derives region boundaries from those fields rather than searching for directory signatures. Arithmetic must be checked for overflow because corrupt BPB values can otherwise direct reads outside the volume.

Clusters and FAT Classification #

A cluster is the filesystem’s allocation unit and contains a power-of-two number of sectors in Microsoft-defined FAT formats. Cluster numbers 0 and 1 are reserved; data clusters begin at 2. The data-cluster count follows from the BPB:

root_dir_sectors =
  ceil(root_entry_count × 32 / bytes_per_sector)

first_data_sector =
  reserved_sectors + fat_count × sectors_per_fat + root_dir_sectors

data_clusters =
  floor((total_sectors - first_data_sector) / sectors_per_cluster)

Cluster count, not a label string or partition-type byte, classifies a volume:

Upper practical limits also depend on cluster size, implementation policy, and fields in the BPB. Wider entries permit more clusters but consume more sectors for each FAT copy.

Allocation Entries and Cluster Chains #

Each FAT entry describes the corresponding cluster. Values represent:

• zero for a free cluster;
• another cluster number for the next link in a chain;
• a reserved or bad-cluster marker;
• a value in the end-of-chain range.

A file’s short directory entry stores its first cluster and byte length. Reading the file begins there and follows FAT links until enough bytes have been obtained or an end marker appears. The final cluster can contain slack bytes beyond the logical length. A directory uses the same chain mechanism on FAT32 and for all non-root directories.

Linked allocation allows a file to grow without finding one contiguous extent, but fragmented chains require extra FAT lookups and nonsequential I/O. The table is also a shared point of failure. A loop, out-of-range link, premature end marker, or one cluster claimed by two files makes directory metadata and allocation state inconsistent.

Multiple FAT copies do not form a journal. A writer can fail after updating one copy, the directory entry, or part of a chain. Repair software must choose among stale copies and inferred ownership; byte-for-byte agreement between two copies cannot prove that directory entries are correct. FAT32’s FSInfo free-count and next-free hints can also become stale, so readers must treat them as hints.

Directory Entries and Timestamps #

A standard directory slot is 32 bytes. A short-name entry contains an 8.3 name, attribute flags, timestamp fields, the starting cluster, and file size. FAT32 splits the starting cluster between high and low words. Special first-byte values mark an unused slot or a deleted entry, while the directory attribute distinguishes subdirectories from regular files.

Classic FAT timestamps encode local civil time rather than a UTC instant:

• modification time has two-second resolution;
• modification and creation dates use packed year, month, and day fields;
• creation time can include a tenths-of-a-second field;
• last-access time stores a date but no time of day.

Timezone and daylight-saving interpretation belongs to the implementation, thus copying a volume between systems can change the displayed instant without changing the on-disk bits. Validation must reject impossible dates rather than passing packed values directly to calendar APIs.

VFAT Long File Names #

VFAT preserves compatibility with 8.3 readers by placing long-file-name (LFN) entries immediately before the associated short entry. An LFN slot:

• uses attribute value 0x0F, which old FAT readers do not treat as a regular file;
• stores up to 13 UTF-16 code units in discontiguous fields;
• carries an ordinal indicating its position and whether it is the final slot;
• repeats a checksum derived from the short 8.3 name.

Slots appear on disk in reverse ordinal order, followed by the short entry. A reader reconstructs the name only when ordinals, attributes, and checksum agree. Otherwise, the short name remains the safe identity. UTF-16 code units can contain surrogate pairs, while FAT’s forbidden characters and trailing-space rules remain separate validation concerns.

Boot-Sector Geometry and Partition Metadata #

The BPB retains fields such as sectors per track, head count, media descriptor, and hidden sectors because FAT evolved with BIOS CHS booting and partitioned disks. Modern systems address the volume through LBAs, so geometry values can be synthetic. They describe boot-time compatibility rather than physical platter layout.

The volume boot sector belongs to FAT, whereas an MBR or GPT entry outside the volume locates it. The partition’s start and length must agree with BPB-derived bounds, but one structure does not replace the other. UEFI firmware uses a FAT filesystem for the EFI System Partition under additional UEFI requirements; a random FAT volume does not become an EFI System Partition without the appropriate partition metadata and boot path.

Operational Consequences #

FAT remains suitable for removable media, firmware-visible volumes, and constrained devices because independent implementations can parse it with little machinery. Applications should still flush data before removal, validate all offsets and chain lengths when reading untrusted images, and retain an image before attempting repair. No journal can distinguish a completed update from the intermediate states left by power loss.

References #

• Microsoft FAT32 File System Specification, version 1.03
• UEFI specifications
• Linux kernel VFAT documentation