Design of the FAT file system
The FAT file system is a file system used on MS-DOS and Windows 9x family of operating systems. It continues to be used on mobile devices and embedded systems, and thus is a well-suited file system for data exchange between computers and devices of almost any type and age from 1981 through to the present.
Structure
A FAT file system is composed of four regions:| Region | Size in sectors | Contents | Notes |
| Reserved sectors | Boot Sector | The first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code. Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2. The total count of [|reserved sectors] is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems. For FAT32 file systems, the reserved sectors include a File System Information Sector at logical [|sector 1] and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors [|0] and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, [|7], and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader. | |
| Reserved sectors | FS Information Sector | The first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code. Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2. The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems. For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector [|1] and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader. | |
| Reserved sectors | More reserved sectors | The first reserved sector is the Boot Sector. It includes an area called the BIOS Parameter Block which contains some basic file system information, in particular its type and pointers to the location of the other sections, and usually contains the operating system's boot loader code. Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2. The total count of reserved sectors is indicated by a field inside the Boot Sector, and is usually 32 on FAT32 file systems. For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6. While many other vendors have continued to utilize a single-sector setup for the bootstrap loader, Microsoft's boot sector code has grown to span over logical sectors 0 and 2 since the introduction of FAT32, with logical sector 0 depending on sub-routines in logical sector 2. The Backup Boot Sector area consists of three logical sectors 6, 7, and 8 as well. In some cases, Microsoft also uses sector 12 of the reserved sectors area for an extended boot loader. | |
| FAT Region | * | File Allocation Table #1 | This typically contains two copies of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities. These are maps of the [|Data Region], indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors. Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. The first two clusters in the map contain special values. |
| FAT Region | * | [|File Allocation Table] #2... | This typically contains two copies of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities. These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors. Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. The first two clusters in the map contain special values. |
| Root [|Directory] Region | / | Root Directory | This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here. |
| Data Region | * | Data Region ... | This is where the actual file and directory data is stored and takes up most of the partition. FAT32 typically commences the Root [|Directory Table] in cluster number 2: the first cluster of the Data Region. |
FAT uses little-endian format for all entries in the header and the FAT. It is possible to allocate more FAT sectors than necessary for the number of clusters. The end of the last sector of each FAT copy can be unused if there are no corresponding clusters. The total number of sectors can be larger than the number of sectors used by data, FATs, the root directory, and hidden sectors including the boot sector: this would result in unused sectors at the end of the volume. If a partition contains more sectors than the total number of sectors occupied by the file system it would also result in unused sectors, at the end of the partition, after the volume.
Reserved sectors area
Boot Sector
On non-partitioned storage devices, such as floppy disks, the Boot Sector is the first sector. For partitioned storage devices such as hard disks, the Boot Sector is the first sector of a partition, as specified in the partition table of the device.| Byte offset | Length | Contents |
| 0x000 | 3 | Jump instruction. If the boot sector has a valid signature residing in the last two bytes of the boot sector and this volume is booted from, the prior boot loader will pass execution to this entry point with certain register values, and the jump instruction will then skip past the rest of the header. See Volume Boot Record. Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP or a near jump DOS 2.x formatted disks as well as on some. For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP, whereas MS-DOS/PC DOS do not. The presence of one of these opstring patterns serves as indicator to DOS 3.3 and higher that some kind of BPB is present, while for DOS 1.x volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT. |
| 0x003 | 8 | OEM Name. This value determines in which system the disk was formatted. Although officially documented as free for OEM use, MS-DOS/PC DOS, Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied upon and how to interpret them. Therefore, setting the OEM label to arbitrary or bogus values may cause MS-DOS, PC DOS and OS/2 to not recognize the volume properly and cause data corruption on writes. Common examples are " IBM␠␠3.3", "MSDOS5.0", "MSWIN4.1", "IBM␠␠7.1", "mkdosfs␠", and "FreeDOS␠".Some vendors store licensing info or access keys in this entry. The Volume Tracker in Windows 95/98/SE/ME will overwrite the OEM label with " ?????IHC" signatures even on a seemingly read-only disk access if the medium is not write-protected. Given the dependency on certain values explained above, this may, depending on the actual BPB format and contents, cause MS-DOS/PC DOS and OS/2 to no longer recognize a medium and throw error messages despite the fact that the medium is not defective and can still be read without problems under other operating systems. Windows 9x reads that self-marked disks without any problems but giving some strange values for non-meaning parameters which not exist or are not used when the disk was formatted with older BPB specification, e.g. disk serial number. This applies only to removable disk drives.Some boot loaders make adjustments or refuse to pass control to a boot sector depending on certain values detected here. The boot ROM of the Wang Professional Computer will only treat a disk as bootable if the first four characters of the OEM label are " Wang". Similarly, the ROM BIOS of the Philips :YES will only boot from a disk if the first four characters of the OEM label are ":YES".If, in an FAT32 EBPB, the signature at sector offset is and both total sector entries are 0, the file system entry may serve as a 64-bit total sector count entry and the OEM label entry may be used as alternative file system type instead of the normal entry at offset. In a similar fashion, if this entry is set to " EXFAT␠␠␠", it indicates the usage of an exFAT BPB located at sector offset to, whereas NTFS volumes use "NTFS␠␠␠␠" to indicate an NTFS BPB. |
| 0x00B | varies | BIOS Parameter Block, Extended BIOS Parameter Block or FAT32 Extended BIOS Parameter Block ; size and contents varies between operating systems and versions, see below |
| varies | varies | File system and operating system specific boot code; often starts immediately behind BPB, but sometimes additional "private" boot loader data is stored between the end of the BPB and the start of the boot code; therefore the jump at offset cannot be used to reliably derive the exact BPB format from. |
| 0x1FD | 1 | Physical drive number. With OS/2 1.0 and DOS 4.0, this entry moved to sector offset . Most Microsoft and IBM boot sectors maintain values of at offset and ever since, although they are not part of the signature at. If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured to dynamically update this entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value. |
| 0x1FE | 2 | Boot sector signature. This signature indicates an IBM PC compatible boot code and is tested by most boot loaders residing in the System BIOS or the MBR before passing execution to the boot sector's boot code. This signature does not indicate a particular file system or operating system. Since this signature is not present on all FAT-formatted disks, operating systems must not rely on this signature to be present when logging in volumes. Formatting tools must not write this signature if the written boot sector does not contain at least an x86-compatible dummy boot loader stub; at minimum, it must halt the CPU in an endless loop or issue an INT 19h and RETF. These opstrings should not be used at sector offset, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use at sector offset to catch the CPU in a tight loop while maintaining an opcode pattern recognized by MS-DOS/PC DOS. This signature must be located at fixed sector offset for sector sizes 512 or higher. If the physical sector size is larger, it may be repeated at the end of the physical sector. Atari STs will assume a disk to be Atari 68000 bootable if the checksum over the 256 big-endian words of the boot sector equals. If the boot loader code is IBM compatible, it is important to ensure that the checksum over the boot sector does not match this checksum by accident. If this would happen to be the case, changing an unused bit can be used to ensure this condition is not met. In rare cases, a reversed signature has been observed on disk images. This can be the result of a faulty implementation in the formatting tool based on faulty documentation, but it may also indicate a swapped byte order of the disk image, which might have occurred in transfer between platforms using a different endianness. BPB values and FAT12, FAT16 and FAT32 file systems are meant to use little-endian representation only and there are no known implementations of variants using big-endian values instead. |
| Byte offset | Length | Contents |
| 0x000 | 2 | Jump instruction. Original Atari ST boot sectors start with a 68000 BRA.S instruction. For compatibility with PC operating systems, Atari ST formatted disks since TOS 1.4 start with instead. |
| 0x002 | 6 | OEM Name, e.g., "Loader" on volumes containing an Atari ST boot loader. See OEM Name precautions for PC formatted disks above. The offset and length of this entry are different compared to the entry on PC formatted disks. |
| 0x008 | 3 | Disk serial number, used by Atari ST to detect a disk change. This value must be changed if the disk content is externally changed, otherwise Atari STs may not recognize the change on re-insertion. This entry overlaps the OEM Name field on PC formatted disks. For maximum compatibility, it may be necessary to match certain patterns here; see above. |
| 0x00B | [|19] | DOS 3.0 BIOS Parameter Block |
| 0x01E | varies | Private boot sector data |
| varies | varies | File system and operating system specific Atari ST boot code. No assumptions must be made in regard to the load position of the code, which must be relocatable. If loading an operating system fails, the code can return to the Atari ST BIOS with a 68000 RTS instruction and all registers unaltered. |
| 0x1FE | 2 | Checksum. The 16-bit checksum over the 256 big-endian words of the 512 bytes boot sector including this word must match the magic value in order to indicate an Atari ST 68000 executable boot sector code. This checksum entry can be used to align the checksum accordingly. If the [|logical sector size] is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled. Since some PC operating systems erroneously do not accept FAT formatted floppies if the signature is not present here, it is advisable to place the in this place and use an unused word in the private data or the boot code area or the serial number in order to ensure that the checksum is not matched. |
| Byte offset | Length | Contents |
| 0x000 | 3 | Dummy jump instruction. |
| 0x003 | 8 | OEM Name. |
| 0x00B | 19 | DOS 3.0 BPB |
| 0x01E | varies | MSX-DOS 1 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 1 machines jump to when passing control to the boot sector. This location overlaps with BPB formats since DOS 3.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here. |
| 0x020 | 6 | MSX-DOS 2 volume signature "VOL_ID". |
| 0x026 | 1 | MSX-DOS 2 undelete flag. |
| 0x027 | 4 | MSX-DOS 2 disk serial number. If the "VOL_ID" signature is present at sector offset, MSX-DOS 2 stores a volume serial number here for media change detection. |
| 0x02B | 5 | reserved |
| 0x030 | varies | MSX-DOS 2 code entry point for Z80 processors into MSX boot code. This is where MSX-DOS 2 machines jump to when passing control to the boot sector. This location overlaps with [|EBPB] formats since DOS 4.0 / OS/2 1.2 or the x86 compatible boot sector code of IBM PC compatible boot sectors and will lead to a crash on the MSX machine unless special precautions have been taken such as catching the CPU in a tight loop here. |
| 0x1FE | 2 | Signature |
BIOS Parameter Block
| Sector offset | BPB offset | Length | Contents |
| 0x00B | 0x00 | 2 | Bytes per logical sector; the most common value is 512. Some operating systems don't support other sector sizes. For simplicity and maximum performance, the logical sector size is often identical to a disk's physical sector size, but can be larger or smaller in some scenarios. The minimum allowed value for non-bootable FAT12/FAT16 volumes with up to 65,535 logical sectors is 32 bytes, or 64 bytes for more than 65,535 logical sectors. The minimum practical value is 128. Some pre-DOS 3.31 OEM versions of DOS used logical sector sizes up to 8192 bytes for logical sectored FATs. Atari ST GEMDOS supports logical sector sizes between 512 and 4096. DR-DOS supports booting off FAT12/FAT16 volumes with logical sector sizes up to 32 KB and INT 13h implementations supporting physical sectors up to 1024 bytes/sector. The minimum logical sector size for standard FAT32 volumes is 512 bytes, which can be reduced downto 128 bytes without support for the FS Information Sector. Floppy drives and controllers use physical sector sizes of 128, 256, 512 and 1024 bytes. The Atari Portfolio supports a sector size of 512 for volumes larger than 64 KB, 256 bytes for volumes larger 32 KB and 128 bytes for smaller volumes. Magneto-optical drives used sector sizes of 512, 1024 and 2048 bytes. In 2005 some Seagate custom hard disks used sector sizes of 1024 bytes instead of the default 512 bytes. Advanced Format hard disks use 4096 bytes per sector since 2010, but will also be able to emulate 512 byte sectors for a transitional period. Linux, and by extension Android, supports a logical sector size far larger, officially documented in the Man page for the filesystem utilities as up to 32KB. |
| 0x00D | 0x02 | 1 | Logical sectors per cluster. Allowed values are 1, 2, 4, 8, 16, 32, 64, and 128. Some MS-DOS 3.x versions supported a maximum cluster size of 4 KB only, whereas modern MS-DOS/PC DOS and Windows 95 support a maximum cluster size of 32 KB. Windows 98/SE/ME partially support a cluster size of 64 KB as well, but some FCB services are not available on such disks and various applications fail to work. The Windows NT family and some alternative DOS versions such as PTS-DOS fully support 64 KB clusters. For most DOS-based operating systems, the maximum cluster size remains at 32 KB even for sector sizes larger than 512 bytes. For logical sector sizes of 1 KB, 2 KB and 4 KB, Windows NT 4.0 supports cluster sizes of 128 KB, while for 2 KB and 4 KB sectors the cluster size can reach 256 KB. Some versions of DR-DOS provide limited support for 128 KB clusters with 512 bytes/sector using a sectors/cluster value of 0. MS-DOS/PC DOS will hang on startup if this value is erroneously specified as 0. |
| 0x00E | 0x03 | 2 | Count of reserved logical sectors. The number of logical sectors before the first FAT in the file system image. At least 1 for this sector, usually 32 for FAT32. Since DR-DOS 7.0x FAT32 formatted volumes use a single-sector boot sector, FS info sector and backup sector, some volumes formatted under DR-DOS use a value of 4 here. |
| 0x010 | 0x05 | 1 | Number of File Allocation Tables. Almost always 2; RAM disks might use 1. Most versions of MS-DOS/PC DOS do not support more than 2 FATs. Some DOS operating systems support only two FATs in their built-in disk driver, but support other FAT counts for block device drivers loaded later on. Volumes declaring 2 FATs in this entry will never be treated as TFAT volumes. If the value differs from 2, some Microsoft operating systems may attempt to mount the volume as a TFAT volume and use the second cluster of the first FAT to determine the TFAT status. |
| 0x011 | 0x06 | 2 | Maximum number of FAT12 or FAT16 root directory entries. 0 for FAT32, where the root directory is stored in ordinary data clusters; see offset in FAT32 EBPBs. A value of 0 without a FAT32 EBPB may also indicate a variable-sized root directory in some non-standard FAT12 and FAT16 implementations, which store the root directory start cluster in the cluster 1 entry in the FAT. This extension, however, is not supported by mainstream operating systems, as it can conflict with other uses of the [|cluster 1] entry for maintenance flags, the current end-of-chain-marker, or TFAT extensions. This value must be adjusted so that directory entries always consume full logical sectors, given that each directory entry takes up 32 bytes. MS-DOS/PC DOS require this value to be a multiple of 16. The maximum value supported on floppy disks is 240, the maximum value supported by MS-DOS/PC DOS on hard disks is 512. DR-DOS supports booting off FAT12/FAT16 volumes, if the boot file is located in the first 2048 root directory entries. |
| 0x013 | 0x08 | 2 | Total logical sectors. 0 for FAT32. |
| 0x015 | 0x0A | 1 | Media descriptor : ;0xE5:
Certain operating systems before DOS 3.2 ignore the boot sector parameters altogether and use the media descriptor value from the first byte of the FAT to choose among internally pre-defined parameter templates. Must be greater or equal to since DOS 4.0. On removable drives, DR-DOS will assume the presence of a BPB if this value is greater or equal to, whereas for fixed disks, it must be to assume the presence of a BPB. Initially, these values were meant to be used as bit flags; for any removable media without a recognized BPB format and a media descriptor of either or to MS-DOS/PC DOS treats bit 1 as a flag to choose a 9-sectors per track format rather than an 8-sectors format, and bit 0 as a flag to indicate double-sided media. Values to and to are reserved and must not be used. |
| 0x016 | 0x0B | 2 | Logical sectors per File Allocation Table for FAT12/FAT16. FAT32 sets this to 0 and uses the 32-bit value at offset instead. |
DOS 3.0 BPB:
The following extensions were documented since DOS 3.0, however, they were already supported by some issues of DOS 2.11. MS-DOS 3.10 still supported the DOS 2.0 format, but could use the DOS 3.0 format as well.
| Sector offset | BPB offset | Length | Contents |
| 0x00B | 0x00 | [|13] | DOS 2.0 BPB |
| 0x018 | 0x0D | 2 | Physical sectors per track for disks with INT 13h CHS geometry, e.g., 15 for a "1.20 MB" floppy. A zero entry indicates that this entry is reserved, but not used. |
| 0x01A | 0x0F | 2 | Number of heads for disks with INT 13h CHS geometry, e.g., 2 for a double sided floppy. A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used. |
| 0x01C | 0x11 | 2 | Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned. This DOS 3.0 entry is incompatible with a similar entry at offset in BPBs since DOS 3.31. It must not be used if the logical sectors entry at offset is zero. |
DOS 3.2 BPB:
Officially, MS-DOS 3.20 still used the DOS 3.0 format, but
SYS and FORMAT were adapted to support a 6 bytes longer format already.| Sector offset | BPB offset | Length | Contents |
| 0x00B | 0x00 | 19 | DOS 3.0 BPB |
| 0x01E | 0x13 | 2 | Total logical sectors including hidden sectors. This DOS 3.2 entry is incompatible with a similar entry at offset in BPBs since DOS 3.31. It must not be used if the logical sectors entry at offset is zero. |
DOS 3.31 BPB:
Officially introduced with DOS 3.31 and not used by DOS 3.2, some DOS 3.2 utilities were designed to be aware of this new format already. Official documentation recommends to trust these values only if the logical sectors entry at offset is zero.
| Sector offset | BPB offset | Length | Contents |
| 0x00B | 0x00 | 13 | DOS 2.0 BPB |
| 0x018 | 0x0D | 2 | Physical sectors per track for disks with INT 13h CHS geometry, e.g., 18 for a "1.44 MB" floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0. A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated. |
| 0x01A | 0x0F | 2 | Number of heads for disks with INT 13h CHS geometry, e.g., 2 for a double sided floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0. A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated. |
| 0x01C | 0x11 | 4 | Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned. This DOS 3.31 entry is incompatible with a similar entry at offset in DOS 3.0-3.3 BPBs. At least, it can be trusted if it holds zero, or if the logical sectors entry at offset is zero. If this belongs to an Advanced Active Partition selected at boot time, the BPB entry will be dynamically updated by the enhanced MBR to reflect the "relative sectors" value in the partition table, stored at offset in the AAP or NEWLDR MBR, so that it becomes possible to boot the operating system from EBRs. |
| 0x020 | 0x15 | 4 | Total logical sectors. This DOS 3.31 entry is incompatible with a similar entry at offset in DOS 3.2-3.3 BPBs. Officially, it must be used only if the logical sectors entry at offset is zero, but some operating systems use this entry also for smaller disks. For partitioned media, if this and the entry at are both 0, many operating systems will retrieve the value from the corresponding partition's entry in the MBR instead. If both of these entries are 0 on volumes using a with signature, values exceeding the 4,294,967,295 limit can use a 64-bit entry at offset instead. |
A simple formula translates a volume's given cluster number
CN to a logical sector number LSN:- Determine
SSA=RSC+FN×SF+ceil, where the reserved sector countRSCis stored at offset, the number of FATsFNat offset, the sectors per FATSFat offset or , the root directory entriesRDEat offset, the sector sizeSSat offset, andceilrounds up to a whole number. - Determine
LSN=SSA+×SC, where the sectors per clusterSCare stored at offset.
LSN and LBA addresses become the same for as long as a volume's logical sector size is identical to the underlying medium's physical sector size. Under these conditions, it is also simple to translate between CHS addresses and LSNs as well:LSN=SPT×+SN−1, where the sectors per track SPT are stored at offset, and the number of sides NOS at offset. Track number TN, head number HN, and sector number SN correspond to Cylinder-head-sector: the formula gives the known CHS to LBA translation.[|Extended BIOS Parameter Block]
Further structure used by FAT12 and FAT16 since OS/2 1.0 and DOS 4.0, also known as Extended BIOS Parameter Block :| Sector offset | EBPB offset | Length | Contents |
| 0x00B | 0x00 | 25 | DOS 3.31 BPB |
| 0x024 | 0x19 | 1 | Physical drive number removable media, for. Allowed values for possible physical drives depending on BIOS are - and -. Values and are reserved for internal purposes such as remote or ROM boot and should never occur on disk. Some boot loaders such as the MS-DOS/PC DOS boot loader use this value when loading the operating system, others ignore it altogether or use the drive number provided in the DL register by the underlying boot loader. The entry is sometimes changed by the SYS command or it can be dynamically fixed up by the prior bootstrap loader in order to force the boot sector code to load the operating system from alternative physical disks than the default. A similar entry existed in DOS 3.2 to 3.31 boot sectors at sector offset. If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured to dynamically update this EBPB entry to the DL value provided at boot time or the value stored in the partition table. This enables booting off alternative drives, even when the VBR code ignores the DL value. |
| 0x025 | 0x1A | 1 | Reserved;
|
| 0x026 | 0x1B | 1 | Extended boot signature. |
| 0x027 | 0x1C | 4 | Volume ID Typically the serial number "xxxx-xxxx" is created by a 16-bit addition of both DX values returned by INT 21h/AH=2Ah and INT 21h/AH=2Ch for the high word and another 16-bit addition of both CX values for the low word of the serial number. Alternatively, some DR-DOS disk utilities provide a /# option to generate a human-readable time stamp "mmdd-hhmm" build from BCD-encoded 8-bit values for the month, day, hour and minute instead of a serial number. |
| 0x02B | 0x20 | 11 | Partition Volume Label, padded with blanks, e.g., "NO␠NAME␠␠␠␠" Software changing the directory volume label in the file system should also update this entry, but not all software does. The partition volume label is typically displayed in partitioning tools since it is accessible without mounting the volume. Supported since OS/2 1.2 and MS-DOS 4.0 and higher.Not available if the signature at is set to. This area was used by boot sectors of DOS 3.2 to 3.3 to store a private copy of the Disk Parameter Table instead of using the INT 1Eh pointer to retrieve the ROM table as in later issues of the boot sector. The re-usage of this location for the mostly cosmetical partition volume label minimized problems if some older system utilities would still attempt to patch the former DPT. |
| 0x036 | 0x2B | 8 | File system type, padded with blanks, e.g., "FAT12␠␠␠", "FAT16␠␠␠", "FAT␠␠␠␠␠"This entry is meant for display purposes only and must not be used by the operating system to identify the type of the file system. Nevertheless, it is sometimes used for identification purposes by third-party software and therefore the values should not differ from those officially used. Supported since OS/2 1.2 and MS-DOS 4.0 and higher. Not available if the signature at is set to. |
FAT32 Extended BIOS Parameter Block
In essence FAT32 inserts 28 bytes into the EBPB, followed by the remaining 26 EBPB bytes as shown above for FAT12 and FAT16. Microsoft and IBM operating systems determine the type of FAT file system used on a volume solely by the number of clusters, not by the used BPB format or the indicated file system type, that is, it is technically possible to use a "FAT32 EBPB" also for FAT12 and FAT16 volumes as well as a DOS 4.0 EBPB for small FAT32 volumes. Since such volumes were found to be created by Windows operating systems under some odd conditions, operating systems should be prepared to cope with these hybrid forms.| Sector offset | FAT32 EBPB offset | Length | Contents |
| 0x00B | 0x00 | 25 | DOS 3.31 BPB |
| 0x024 | 0x19 | 4 | Logical sectors per file allocation table. The byte at offset in this entry should never become or in order to avoid any misinterpretation with the EBPB format under non-FAT32 aware operating systems. Fortunately, under normal circumstances, this cannot happen, as a FAT32 file system has at most 0xffffff6 = 268435446 clusters. One Fat sector fits 512 / 4 = 128 cluster descriptors. So at most only ceil = 2097152 = 0x200000 sectors would be needed, making third byte of the number of FAT sectors 0x20 at most, which is less than the forbidden 0x28 and 0x29 values. |
| 0x028 | 0x1D | 2 | Drive description / mirroring flags DR-DOS 7.07 FAT32 boot sectors with dual LBA and CHS support utilize bits 15-8 to store an access flag and part of a message. These bits contain either bit pattern or . The byte is also used for the second character in a potential "No␠IBMBIO␠␠COM" error message. Formatting tools or non-DR SYS-type tools may clear these bits, but other disk tools should leave bits 15-8 unchanged. |
| 0x02A | 0x1F | 2 | Version. The high byte of the version number is stored at offset, and the low byte at offset. FAT32 implementations should refuse to mount volumes with version numbers unknown by them. |
| 0x02C | 0x21 | 4 | Cluster number of root directory start, typically 2 if it contains no bad sector. A cluster value of 0 is not officially allowed and can never indicate a valid root directory start cluster. Some non-standard FAT32 implementations may treat it as an indicator to search for a fixed-sized root directory where it would be expected on FAT16 volumes; see offset. |
| 0x030 | 0x25 | 2 | Logical sector number of FS Information Sector, typically 1, i.e., the second of the three FAT32 boot sectors. Some FAT32 implementations support a slight variation of Microsoft's specification in making the FS Information Sector optional by specifying a value of in this entry. Since logical sector 0 can never be a valid FS Information Sector, but FS Information Sectors use the same signature as found on many boot sectors, file system implementations should never attempt to use logical sector 0 as FS Information sector and instead assume that the feature is unsupported on that particular volume. Without a FS Information Sector, the minimum allowed logical sector size of FAT32 volumes can be reduced downto 128 bytes for special purposes. |
| 0x032 | 0x27 | 2 | First logical sector number of a copy of the three FAT32 boot sectors, typically 6. Since DR-DOS 7.0x FAT32 formatted volumes use a single-sector boot sector, some volumes formatted under DR-DOS use a value of 2 here. Values of are reserved and indicate that no backup sector is available. |
| 0x034 | 0x29 | 12 | Reserved DR-DOS 7.07 FAT32 boot sectors use these 12 bytes to store the filename of the " IBMBIO␠␠COM" file to be loaded and executed by the boot sector, followed by a terminating NUL character. This is also part of an error message, indicating the actual boot file name and access method. |
| 0x040 | 0x35 | 1 | Cf. for FAT12/FAT16 exFAT BPBs are located at sector offset to, overlapping all the remaining entries of a standard FAT32 EBPB including this one. They can be detected via their OEM label signature " EXFAT␠␠␠" at sector offset. In this case, the bytes at to are normally set to. |
| 0x041 | 0x36 | 1 | Cf. for FAT12/FAT16 May hold format filler byte artifacts after partitioning with MS-DOS FDISK, but not yet formatted. |
| 0x042 | 0x37 | 1 | Cf. for FAT12/FAT16 Most FAT32 file system implementations do not support an alternative signature of to indicate a shortened form of the FAT32 EBPB with only the serial number following, but since these 19 mostly unused bytes might serve different purposes in some scenarios, implementations should accept as an alternative signature and then fall back to use the [|directory volume label] in the file system instead of in the EBPB for compatibility with potential extensions. |
| 0x043 | 0x38 | 4 | Cf. for FAT12/FAT16 |
| 0x047 | 0x3C | 11 | Cf. for FAT12/FAT16 Not available if the signature at offset is set to. |
| 0x052 | 0x47 | 8 | Cf. for FAT12/FAT16. Not available if the signature at is set to. If both total logical sectors entries at offset and are 0 on volumes using a FAT32 EBPB with signature, volumes with more than 4,294,967,295 sectors can use this entry as 64-bit total logical sectors entry instead. In this case, the OEM label at sector offset may be retrieved as new-style file system type instead. |
Exceptions
Versions of DOS before 3.2 totally or partially relied on the media descriptor byte in the BPB or the FAT ID byte in [|cluster 0] of the first FAT in order to determine FAT12 diskette formats even if a BPB is present. Depending on the FAT ID found and the drive type detected they default to use one of the following BPB prototypes instead of using the values actually stored in the BPB.Originally, the FAT ID was meant to be a bit flag with all bits set except for bit 2 cleared to indicate an 80 track format, bit 1 cleared to indicate a 9 sector format, and bit 0 cleared to indicate a single-sided format, but this scheme was not followed by all OEMs and became obsolete with the introduction of hard disks and high-density formats. Also, the various 8-inch formats supported by 86-DOS and MS-DOS do not fit this scheme.
Microsoft recommends to distinguish between the two 8-inch formats for FAT ID by trying to read of a single-density address mark. If this results in an error, the medium must be double-density.
The table does not list a number of incompatible 8-inch and 5.25-inch FAT12 floppy formats supported by 86-DOS, which differ either in the size of the directory entries or in the extent of the reserved sectors area.
The implementation of a single-sided 315 KB FAT12 format used in MS-DOS for the Apricot PC and F1e had a different boot sector layout, to accommodate that computer's non-IBM compatible BIOS. The jump instruction and OEM name were omitted, and the MS-DOS BPB parameters were located at offset. The Portable, F1, PC duo and Xi FD supported a non-standard double-sided 720 KB FAT12 format instead. The differences in the boot sector layout and media IDs made these formats incompatible with many other operating systems. The geometry parameters for these formats are:
- 315 KB: Bytes per logical sector: 512 bytes, logical sectors per cluster: 1, reserved logical sectors: 1, number of FATs: 2, root directory entries: 128, total logical sectors: 630, FAT ID:, logical sectors per FAT: 2, physical sectors per track: 9, number of heads: 1.
- 720 KB: Bytes per logical sector: 512 bytes, logical sectors per cluster: 2, reserved logical sectors: 1, number of FATs: 2, root directory entries: 176, total logical sectors: 1440, FAT ID:, logical sectors per FAT: 3, physical sectors per track: 9, number of heads: 2.
The DOS Plus adaptation for the BBC Master 512 supported two FAT12 formats on 80-track, double-sided, double-density 5.25" drives, which did not use conventional boot sectors at all. 800 KB data disks omitted a boot sector and began with a single copy of the FAT. The first byte of the relocated FAT in logical sector 0 was used to determine the disk's capacity. 640 KB boot disks began with a miniature ADFS file system containing the boot loader, followed by a single FAT. Also, the 640 KB format differed by using physical CHS sector numbers starting with 0 and incrementing sectors in the order sector-track-head. The FAT started at the beginning of the next track. These differences make these formats unrecognizable by other operating systems. The geometry parameters for these formats are:
- 800 KB: Bytes per logical sector: 1024 bytes, logical sectors per cluster: 1, reserved logical sectors: 0, number of FATs: 1, root directory entries: 192, total logical sectors: 800, FAT ID:, logical sectors per FAT: 2, physical sectors per track: 5, number of heads: 2.
- 640 KB: Bytes per logical sector: 256 bytes, logical sectors per cluster: 8, reserved logical sectors: 16, number of FATs: 1, root directory entries: 112, total logical sectors: 2560, FAT ID:, logical sectors per FAT: 2, physical sectors per track: 16, number of heads: 2.
The DEC Rainbow 100 supported one FAT12 format on 80-track, single-sided, quad-density 5.25" drives. The first two tracks were reserved for the boot loader, but didn't contain an MBR nor a BPB. The boot sector was Z80 code beginning with DI. The 8088 bootstrap was loaded by the Z80. Track 1, side 0, sector 2 starts with the Media/FAT ID byte. Unformatted disks use instead. The file system starts on track 2, side 0, sector 1. There are 2 copies of the FAT and 96 entries in the root directory. In addition, there is a physical to logical track mapping to effect a 2:1 sector interleaving. The disks were formatted with the physical sectors in order numbered 1 to 10 on each track after the reserved tracks, but the logical sectors from 1 to 10 were stored in physical sectors 1, 6, 2, 7, 3, 8, 4, 9, 5, 10.
FS Information Sector
The "FS Information Sector" was introduced in FAT32 for speeding up access times of certain operations. It is located at a logical sector number specified in the FAT32 EBPB boot record at position .| Byte offset | Length | Contents |
| 0x000 | 4 | FS information sector signature For as long as the FS Information Sector is located in logical sector 1, the location, where the FAT typically started in FAT12 and FAT16 file systems, the presence of this signature ensures that early versions of DOS will never attempt to mount a FAT32 volume, as they expect the values in cluster 0 and cluster 1 to follow certain bit patterns, which are not met by this signature. |
| 0x004 | 480 | Reserved |
| 0x1E4 | 4 | FS information sector signature |
| 0x1E8 | 4 | Last known number of free data clusters on the volume, or if unknown. Should be set to during format and updated by the operating system later on. Must not be absolutely relied upon to be correct in all scenarios. Before using this value, the operating system should sanity check this value to be less than or equal to the volume's count of clusters. |
| 0x1EC | 4 | Number of the most recently known to be allocated data cluster. Should be set to during format and updated by the operating system later on. With the system should start at cluster. Must not be absolutely relied upon to be correct in all scenarios. Before using this value, the operating system should sanity check this value to be a valid cluster number on the volume. |
| 0x1F0 | 12 | Reserved |
| 0x1FC | 4 | FS information sector signature |
The sector's data may be outdated and not reflect the current media contents, because not all operating systems update or use this sector, and even if they do, the contents is not valid when the medium has been ejected without properly unmounting the volume or after a power-failure. Therefore, operating systems should first inspect a volume's optional shutdown status bitflags residing in the FAT entry of cluster 1 or the FAT32 EBPB at offset and ignore the data stored in the FS information sector, if these bitflags indicate that the volume was not properly unmounted before. This does not cause any problems other than a possible speed penalty for the first free space query or data cluster allocation; see fragmentation.
If this sector is present on a FAT32 volume, the minimum allowed logical sector size is 512 bytes, whereas otherwise it would be 128 bytes. Some FAT32 implementations support a slight variation of Microsoft's specification by making the FS information sector optional by specifying a value of in the entry at offset.
FAT region
File Allocation Table
Cluster map
A volume's data area is divided into identically sized clusters—small blocks of contiguous space. Cluster sizes vary depending on the type of FAT file system being used and the size of the drive; typical cluster sizes range from 2 to.Each file may occupy one or more clusters depending on its size. Thus, a file is represented in the FAT by a singly linked list. The FAT is made up of entries that are 12, 16, or 32 bits long, depending on whether it's FAT12, FAT16, or FAT32. The consecutive entries correspond to consecutive clusters, and the value of the entry is a link telling what the next cluster in the particular file is. Looking at the entry corresponding to that cluster tells where the next one is, and so on, until there's an entry that indicates that it corresponds to the last cluster in the cluster chain holding that file. The clusters are not necessarily adjacent to one another on the disk's surface but are often instead fragmented throughout the Data Region.
Each version of the FAT file system uses a different size for FAT entries. Smaller numbers result in a smaller FAT, but waste space in large partitions by needing to allocate in large clusters.
The FAT12 file system uses 12 bits per FAT entry, thus two entries span 3 bytes. It is consistently little-endian: if those three bytes are considered as one little-endian 24-bit number, the 12 least significant bits represent the first entry and the 12 most significant bits the second. In other words, while the low eight bits of the first cluster in the row are stored in the first byte, the top four bits are stored in the low nibble of the second byte, whereas the low four bits of the subsequent cluster in the row are stored in the high nibble of the second byte and its higher eight bits in the third byte.
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
| +0000 | F0 | FF | FF | 03 | 40 | 00 | 05 | 60 | 00 | 07 | 80 | 00 | FF | AF | 00 | 14 |
| +0010 | C0 | 00 | 0D | E0 | 00 | 0F | 00 | 01 | 11 | F0 | FF | 00 | F0 | FF | 15 | 60 |
| +0020 | 01 | 19 | 70 | FF | F7 | AF | 01 | FF | 0F | 00 | 00 | 70 | FF | 00 | 00 | 00 |
The FAT16 file system uses 16 bits per FAT entry, thus one entry spans two bytes in little-endian byte order:
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
| +0000 | F0 | FF | FF | FF | 03 | 00 | 04 | 00 | 05 | 00 | 06 | 00 | 07 | 00 | 08 | 00 |
| +0010 | FF | FF | 0A | 00 | 14 | 00 | 0C | 00 | 0D | 00 | 0E | 00 | 0F | 00 | 10 | 00 |
| +0020 | 11 | 00 | FF | FF | 00 | 00 | FF | FF | 15 | 00 | 16 | 00 | 19 | 00 | F7 | FF |
| +0030 | F7 | FF | 1A | 00 | FF | FF | 00 | 00 | 00 | 00 | F7 | FF | 00 | 00 | 00 | 00 |
The FAT32 file system uses 32 bits per FAT entry, thus one entry spans four bytes in little-endian byte order. The four top bits of each entry are reserved for other purposes; they are cleared during formatting and should not be changed otherwise. They must be masked off before interpreting the entry as 28-bit cluster address.
| Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
| +0000 | F0 | FF | FF | 0F | FF | FF | FF | 0F | FF | FF | FF | 0F | 04 | 00 | 00 | 00 |
| +0010 | 05 | 00 | 00 | 00 | 06 | 00 | 00 | 00 | 07 | 00 | 00 | 00 | 08 | 00 | 00 | 00 |
| +0020 | FF | FF | FF | 0F | 0A | 00 | 00 | 00 | 14 | 00 | 00 | 00 | 0C | 00 | 00 | 00 |
| +0030 | 0D | 00 | 00 | 00 | 0E | 00 | 00 | 00 | 0F | 00 | 00 | 00 | 10 | 00 | 00 | 00 |
| +0040 | 11 | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 | FF | FF | FF | 0F |
| +0050 | 15 | 00 | 00 | 00 | 16 | 00 | 00 | 00 | 19 | 00 | 00 | 00 | F7 | FF | FF | 0F |
| +0060 | F7 | FF | FF | 0F | 1A | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 |
| +0070 | 00 | 00 | 00 | 00 | F7 | FF | FF | 0F | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
The File Allocation Table is a contiguous number of sectors immediately following the area of reserved sectors. It represents a list of entries that map to each cluster on the volume. Each entry records one of four things:
- the cluster number of the next cluster in a chain
- a special end of cluster-chain entry that indicates the end of a chain
- a special entry to mark a bad cluster
- a zero to note that the cluster is unused
Special entries
The first two entries in a FAT store special values:The first entry holds the FAT ID since MS-DOS 1.20 and PC DOS 1.1 in bits 7-0, which is also copied into the BPB of the boot sector, offset since DOS 2.0. The remaining 4 bits, 8 bits or 20 bits of this entry are always 1. These values were arranged so that the entry would also function as a "trap-all" end-of-chain marker for all data clusters holding a value of zero. Additionally, for FAT IDs other than it is possible to determine the correct nibble and byte order used by the file system driver, however, the FAT file system officially uses a little-endian representation only and there are no known implementations of variants using big-endian values instead. 86-DOS 0.42 up to MS-DOS 1.14 used hard-wired drive profiles instead of a FAT ID, but used this byte to distinguish between media formatted with 32-byte or 16-byte directory entries, as they were used prior to 86-DOS 0.42.
The second entry nominally stores the end-of-cluster-chain marker as used by the formater, but typically always holds / /, that is, with the exception of bits 31-28 on FAT32 volumes these bits are normally always set. Some Microsoft operating systems, however, set these bits if the volume is not the volume holding the running operating system. For DOS 1 and 2, the entry was documented as reserved for future use.
Since DOS 7.1 the two most-significant bits of this cluster entry may hold two optional bitflags representing the current volume status on FAT16 and FAT32, but not on FAT12 volumes. These bitflags are not supported by all operating systems, but operating systems supporting this feature would set these bits on shutdown and clear the most significant bit on startup:
If bit 15 or bit 27 is not set when mounting the volume, the volume was not properly unmounted before shutdown or ejection and thus is in an unknown and possibly "dirty" state. On FAT32 volumes, the FS Information Sector may hold outdated data and thus should not be used. The operating system would then typically run SCANDISK or CHKDSK on the next startup to ensure and possibly reestablish the volume's integrity.
If bit 14 or bit 26 is cleared, the operating system has encountered disk I/O errors on startup, a possible indication for bad sectors. Operating systems aware of this extension will interpret this as a recommendation to carry out a surface scan on the next boot.
If the number of FATs in the BPB is not set to 2, the [|second cluster entry] in the first FAT may also reflect the status of a TFAT volume for TFAT-aware operating systems. If the cluster 1 entry in that FAT holds the value 0, this may indicate that the second FAT represents the last known valid transaction state and should be copied over the first FAT, whereas the first FAT should be copied over the second FAT if all bits are set.
Some non-standard FAT12/FAT16 implementations utilize the cluster 1 entry to store the starting cluster of a variable-sized root directory. This may occur when the number of root directory entries in the BPB holds a value of 0 and no FAT32 EBPB is found. This extension, however, is not supported by mainstream operating systems, as it conflicts with other possible uses of the cluster 1 entry. Most conflicts can be ruled out if this extension is only allowed for FAT12 with less than and FAT16 volumes with less than clusters and 2 FATs.
Because these first two FAT entries store special values, there are no data clusters 0 or 1. The first data cluster is cluster 2, marking the beginning of the data area.
Cluster values
FAT entry values:| FAT12 | FAT16 | FAT32 | Description |
| 0x000 | 0x0000 | Free Cluster; also used by DOS to refer to the parent directory starting cluster in ".." entries of subdirectories of the root directory on FAT12/FAT16 volumes. Otherwise, if this value occurs in cluster chains, file system implementations should treat this like an end-of-chain marker. | |
| 0x001 | 0x0001 | Reserved for internal purposes; MS-DOS/PC DOS use this cluster value as a temporary non-free cluster indicator while constructing cluster chains during file allocation. If this value occurs in on-disk cluster chains, file system implementations should treat this like an end-of-chain marker. | |
| 0x002 - 0xFEF | 0x0002 - 0xFFEF | Used as data clusters; value points to next cluster. MS-DOS/PC DOS accept values up to / / , whereas for Atari GEMDOS only values up to are allowed on FAT16 volumes. | |
| 0xFF0 - 0xFF5 | 0xFFF0 - 0xFFF5 | Reserved in some contexts, or also used as data clusters in some non-standard systems. Volume sizes which would utilize these values as data clusters should be avoided, but if these values occur in existing volumes, the file system must treat them as normal data clusters in cluster-chains, similar to what MS-DOS, PC DOS and DR-DOS do, and should avoid allocating them for files otherwise. MS-DOS/PC DOS 3.3 and higher treats a value of on FAT12 volumes as additional end-of-chain marker similar to -. For compatibility with MS-DOS/PC DOS, file systems should avoid using data cluster in cluster chains on FAT12 volumes. | |
| 0xFF6 | 0xFFF6 | Reserved; do not use. Volumes should not be created which would utilize this value as data cluster, but if this value occurs in existing volumes, the file system must treat it as normal data cluster in cluster-chains, and should avoid allocating it for files otherwise. | |
| 0xFF7 | 0xFFF7 | Bad sector in cluster or reserved cluster. The cutover values for the maximum number of clusters for FAT12 and FAT16 file systems are defined as such that the highest possible data cluster values will always be smaller than this value. Therefore, this value cannot normally occur in cluster-chains, but if it does, it may be treated as a normal data cluster, since could have been a non-standard data cluster on FAT12 volumes before the introduction of the bad cluster marker with DOS 2.0 or the introduction of FAT16 with DOS 3.0, and could have been a non-standard data cluster on FAT16 volumes before the introduction of FAT32 with DOS 7.10. Theoretically, can be part of a valid cluster chain on FAT32 volumes, but disk utilities should avoid creating FAT32 volumes, where this condition could occur. The file system should avoid allocating this cluster for files. Disk utilities must not attempt to restore "lost clusters" holding this value in the FAT, but count them as bad clusters. | |
| 0xFF8 [|–] 0xFFF | 0xFFF8 – 0xFFFF | Last cluster in file. File system implementations must treat all these values as end-of-chain marker at the same time. Most file system implementations use / / as end-of-file marker when allocating files, but versions of Linux before 2.5.40 used / /. Versions of mkdosfs continue to use for the root directory on FAT32 volumes, whereas some disk repair and defragment tools utilize other values in the set. While in the original 8-bit FAT implementation in Microsoft's Standalone Disk BASIC different end markers were used to indicate the number of sectors used up in the last cluster occupied by a file, different end markers were repurposed under DOS to indicate different types of media, with the currently used end marker indicated in the cluster 1 entry, however, this concept does not seem to have been broadly utilized in practice—and to the extent that in some scenarios volumes may not be recognized by some operating systems, if some of the low-order bits of the value stored in cluster 1 are not set. Also, some faulty file system implementations only accept / / as valid end-of-chain marker. File system implementations should check cluster values in cluster-chains against the maximum allowed cluster value calculated by the actual size of the volume and treat higher values as if they were end-of-chain markers as well. |
FAT32 uses 28 bits for cluster numbers. The remaining 4 bits in the 32-bit FAT entry are usually zero, but are reserved and should be left untouched. A standard conformant FAT32 file system driver or maintenance tool must not rely on the upper 4 bits to be zero and it must strip them off before evaluating the cluster number in order to cope with possible future expansions where these bits may be used for other purposes. They must not be cleared by the file system driver when allocating new clusters, but should be cleared during a reformat.
Root directory region
The root directory table in FAT12 and FAT16 file systems occupies the special Root Directory Region location.Data region
Aside from the root directory table in FAT12 and FAT16 file systems, which occupies the special Root Directory Region location, all directory tables are stored in the data region. The actual number of entries in a directory stored in the data region can grow by adding another cluster to the chain in the FAT.Directory table
A directory table is a special type of file that represents a directory. Since 86-DOS 0.42, each file or subdirectory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes, the address of the first cluster of the file/directory's data, the size of the file/directory, and the date and also the time of last modification. Earlier versions of 86-DOS used 16-byte directory entries only, supporting no files larger than 16 MB and no time of last modification.The FAT file system itself does not impose any limits on the depth of a subdirectory tree for as long as there are free clusters available to allocate the subdirectories, however, the internal Current Directory Structure under MS-DOS/PC DOS limits the absolute path of a directory to 66 characters, thereby limiting the maximum supported depth of subdirectories to 32, whatever occurs earlier. Concurrent DOS, Multiuser DOS and DR DOS 3.31 to 6.0 do not store absolute paths to working directories internally and therefore do not show this limitation. The same applies to Atari GEMDOS, but the Atari Desktop does not support more than 8 sub-directory levels. Most applications aware of this extension support paths up to at least 127 bytes. FlexOS, 4680 OS and 4690 OS support a length of up to 127 bytes as well, allowing depths down to 60 levels. PalmDOS, DR DOS 6.0 and higher, Novell DOS, and OpenDOS sport a MS-DOS-compatible CDS and therefore have the same length limits as MS-DOS/PC DOS.
Each entry can be preceded by "fake entries" to support a VFAT long filename ; see further below.
Legal characters for DOS short filenames include the following:
- Upper case letters
A–Z - Numbers
0–9 - Space. Another exception are the internal commands
MKDIR/MDandRMDIR/RDunder DR-DOS which accept single arguments and therefore allow spaces to be entered. -
! # $ % & ' - @ ^ _ ` ~ - Characters 128–228
- Characters 230–255
-
" * / : < > ? \ |
-
+,. ; =
Allowed in long file names only - Lower case letters
a–z
Stored asA–Z; allowed in long file names - Control characters 0–31
- Character 127
The following additional characters are allowed on Atari's GEMDOS, but should be avoided for compatibility with MS-DOS/PC DOS:
-
" +, ; < = > |
...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD". The operating system will strip off one semicolons and pending passwords from the filenames before storing them on disk. The at-sign character is used for filelists by many DR-DOS, PalmDOS, Novell DOS, OpenDOS and Multiuser DOS, System Manager and REAL/32 commands, as well as by 4DOS and may therefore sometimes be difficult to use in filenames.
Under Multiuser DOS and REAL/32, the exclamation mark is not a valid filename character since it is used to separate multiple commands in a single command line.
Under IBM 4680 OS and 4690 OS, the following characters are not allowed in filenames:
-
? * :. ;, ! + = < > " - / \ |
-
@ # $ &
Directory entry
Before Microsoft added support for long filenames and creation/access time stamps, bytes – of the [|directory entry] were used by other operating systems to store additional metadata, most notably the operating systems of the Digital Research family stored file passwords, access rights, owner IDs, and file deletion data there. While Microsoft's newer extensions are not fully compatible with these extensions by default, most of them can coexist in third-party FAT implementations.32-byte directory entries, both in the Root Directory Region and in subdirectories, are of the following format :
| Byte offset | Length | Contents | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 0x00 | 8 | Short file name The first byte can have the following special values: The FlexOS-based operating systems IBM 4680 OS and IBM 4690 OS support unique distribution attributes stored in some bits of the previously reserved areas in the directory entries:
Size limitsThe FAT12, FAT16, FAT16B, and FAT32 variants of the FAT file systems have clear limits based on the number of clusters and the number of sectors per cluster. For the typical value of 512 bytes per sector:
Because each FAT32 entry occupies 32 bits the maximal number of clusters requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is, and storing this value needs more than two bytes. Therefore, FAT32 introduced a new 32-bit value in the FAT32 boot sector immediately following the 32-bit value for the total number of sectors introduced in the FAT16B variant. The boot record extensions introduced with DOS 4.0 start with a magic 40 or 41. Typically FAT drivers look only at the number of clusters to distinguish FAT12, FAT16, and FAT32: the human readable strings identifying the FAT variant in the boot record are ignored, because they exist only for media formatted with DOS 4.0 or later. Determining the number of directory entries per cluster is straightforward. Each entry occupies 32 bytes; this results in 16 entries per sector for a sector size of 512 bytes. The DOS 5 RMDIR/RD command removes the initial "." and ".." entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12, but requires 2 or more sectors per cluster. A FAT12 boot sector without the DOS 4 extensions needs 29 bytes before the first unnecessary FAT16B 32-bit number of hidden sectors, this leaves three bytes for the boot code and the magic at the end of all boot sectors. On Windows NT the smallest supported sector size is 128.On Windows NT operating systems the FORMAT command options /A:128K and /A:256K correspond to the maximal cluster size 0x80 with a sector size 1024 and 2048, respectively. For the common sector size 512 /A:64K yields 128 sectors per cluster.Both editions of each ECMA-107 and ISO/IEC 9293 specify a Max Cluster Number MAX determined by the formula MAX=1+trunc, and reserve cluster numbers MAX+1 up to 4086 and later 65526 for future standardization.Microsoft's EFI FAT32 specification states that any FAT file system with less than 4085 clusters is FAT12, else any FAT file system with less than 65,525 clusters is FAT16, and otherwise it is FAT32. The entry for cluster 0 at the beginning of the FAT must be identical to the [|media descriptor byte] found in the BPB, whereas the entry for cluster 1 reflects the end-of-chain value used by the formatter for cluster chains. The entries for cluster numbers 0 and 1 end at a byte boundary even for FAT12, e.g., for media descriptor. The first data cluster is 2, and consequently the last cluster MAX gets number MAX+1. This results in data cluster numbers 2...4085 for FAT12, 2...65525 for FAT16, and 2...268435445 for FAT32.The only available values reserved for future standardization are therefore and . As noted below "less than 4085" is also used for Linux implementations, or as Microsoft's FAT specification puts it: ...when it says <, it does not mean <=. Note also that the numbers are correct. The first number for FAT12 is 4085; the second number for FAT16 is 65525. These numbers and the "<" signs are not wrong." FragmentationThe FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition. On volumes where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time. While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive. Also, file operations will become slower with growing fragmentation as it takes increasingly longer for the operating system to find files or free clusters. Other file systems, e.g., HPFS or exFAT, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists. Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks. In fact, seeking for files in large subdirectories or computing the free disk space on FAT volumes is one of the most resource intensive operations, as it requires reading the directory tables or even the entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less for which FAT has been designed and optimized originally. With the introduction of FAT32, long seek and scan times became more apparent, particularly on very large volumes. A possible justification suggested by Microsoft's Raymond Chen for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a " DIR" operation, which always displays the free disk space as the last line. Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special file system information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-ATX-style PCs, on plain DOS systems and some battery-powered consumer products.With the huge cluster sizes forced by larger FAT partitions, internal fragmentation in form of disk space waste by file slack due to cluster overhang starts to be a problem as well, especially when there are a great many small files. Various optimizations and tweaks to the implementation of FAT file system drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the file system's inherent design without having to change the layout of the on-disk structures. They can be divided into on-line and off-line methods and work by trying to avoid fragmentation in the file system in the first place, deploying methods to better cope with existing fragmentation, and by reordering and optimizing the on-disk structures. With optimizations in place, the performance on FAT volumes can often reach that of more sophisticated file systems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems. DOS 3.0 and higher will not immediately reuse disk space of deleted files for new allocations but instead seek for previously unused space before starting to use disk space of previously deleted files as well. This not only helps to maintain the integrity of deleted files for as long as possible but also speeds up file allocations and avoids fragmentation, since never before allocated disk space is always unfragmented. DOS accomplishes this by keeping a pointer to the last allocated cluster on each mounted volume in memory and starts searching for free space from this location upwards instead of at the beginning of the FAT, as it was still done by DOS 2.x. If the end of the FAT is reached, it would wrap around to continue the search at the beginning of the FAT until either free space has been found or the original position has been reached again without having found free space. These pointers are initialized to point to the start of the FATs after bootup, but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the FS Information Sector. This mechanism is defeated, however, if an application often deletes and recreates temporary files as the operating system would then try to maintain the integrity of void data effectively causing more fragmentation in the end. In some DOS versions, the usage of a special API function to create temporary files can be used to avoid this problem. Additionally, directory entries of deleted files will be marked since DOS 3.0. DOS 5.0 and higher will start to reuse these entries only when previously unused directory entries have been used up in the table and the system would otherwise have to expand the table itself. Since DOS 3.3 the operating system provides means to improve the performance of file operations with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists or hash tables, which can reduce file seek and open times significantly. Before DOS 5.0 special care must be taken when using such mechanisms in conjunction with disk defragmentation software bypassing the file system or disk drivers.Windows NT will allocate disk space to files on FAT in advance, selecting large contiguous areas, but in case of a failure, files which were being appended will appear larger than they were ever written into, with a lot of random data at the end. Other high-level mechanisms may read in and process larger parts or the complete FAT on startup or on demand when needed and dynamically build up in-memory tree representations of the volume's file structures different from the on-disk structures. This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background. Some of the perceived problems with fragmentation of FAT file systems also result from performance limitations of the underlying block device drivers, which becomes more visible the lesser memory is available for sector buffering and track blocking/deblocking: While the single-tasking DOS had provisions for multi-sector reads and track blocking/deblocking, the operating system and the traditional PC hard disk architecture originally did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks. Such features became available later. Later DOS versions also provided built-in support for look-ahead sector buffering and came with dynamically loadable disk caching programs working on physical or logical sector level, often utilizing EMS or XMS memory and sometimes providing adaptive caching strategies or even run in protected mode through DPMS or Cloaking to increase performance by gaining direct access to the cached data in linear memory rather than through conventional DOS APIs. Write-behind caching was often not enabled by default with Microsoft software given the problem of data loss in case of a power failure or crash, made easier by the lack of hardware protection between applications and the system. VFAT long file namesVFAT Long File Names are stored on a FAT file system using a trick: adding additional entries into the directory before the normal file entry. The additional entries are marked with the Volume Label, System, Hidden, and Read Only attributes, which is a combination that is not expected in the MS-DOS environment, and therefore ignored by MS-DOS programs and third-party utilities. Notably, a directory containing only volume labels is considered as empty and is allowed to be deleted; such a situation appears if files created with long names are deleted from plain DOS. This method is very similar to the DELWATCH method to utilize the volume attribute to hide pending delete files for possible future undeletion since DR DOS 6.0 and higher. It is also similar to a method publicly discussed to store long filenames on Ataris and under Linux in 1992. Because older versions of DOS could mistake LFN names in the root directory for the volume label, VFAT was designed to create a blank volume label in the root directory before adding any LFN name entries. Each phony entry can contain up to 13 UCS-2 characters by using fields in the record which contain file size or time stamps. Up to 20 of these 13-character entries may be chained, supporting a maximum length of 255 UCS-2 characters. If the position of the LFN's last character is not at a directory entry boundary, then a terminator is added in the next character position. Then, if that terminator is also not at the boundary, remaining character positions are filled with. No directory entry containing a lone terminator will exist. LFN entries use the following format:
If there are multiple LFN entries required to represent a file name, the entry representing the end of the filename comes first. The sequence number of this entry has bit 6 set to represent that it is the last logical LFN entry, and it has the highest sequence number. The sequence number decreases in the following entries. The entry representing the start of the filename has sequence number 1. A value of is used to indicate that the entry is deleted. On FAT12 and FAT16 volumes, testing for the values at to be zero and at to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH. For example, a filename like "File with very long filename.ext" would be formatted like this:
A checksum also allows verification of whether a long file name matches the 8.3 name; such a mismatch could occur if a file was deleted and re-created using DOS in the same directory position. The checksum is calculated using the algorithm below. unsigned char lfn_checksum If a filename contains only lowercase letters, or is a combination of a lowercase basename with an uppercase extension, or vice versa; and has no special characters, and fits within the 8.3 limits, a VFAT entry is not created on Windows NT and later versions of Windows such as XP. Instead, two bits in byte of the directory entry are used to indicate that the filename should be considered as entirely or partially lowercase. Specifically, bit 4 means lowercase extension and bit 3 lowercase basename, which allows for combinations such as " example.TXT" or "HELLO.txt" but not "Mixed.txt". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions that see all-uppercase filenames if this extension has been used, and therefore can change the name of a file when it is transported between operating systems, such as on a USB flash drive. Current 2.6.x versions of Linux will recognize this extension when reading ; the mount option shortname determines whether this feature is used when writing. |