Просмотр кода страницы Английская Википедия:Design of the FAT file system

{{Английская Википедия/Панель перехода}}
{{Short description|Computer file system architecture design}}
{{Multiple issues|
{{Technical|date=September 2021}}
{{duplication|dupe=FAT file system|date=January 2023}}
}}
{{Broader|File Allocation Table}}
{{Use dmy dates|date=April 2019|cs1-dates=y}}
{{Infobox file system
| name                    = FAT
| developer               = [[Microsoft]]<!-- original FAT, FAT16, FAT32 -->, [[Seattle Computer Products|SCP]]<!-- FAT12 -->, [[IBM]], [[Compaq]]<!-- Compaq MS-DOS 3.31-->, [[Digital Research]]<!-- lots of extensions -->, [[Novell]]<!-- lots of extensions continuing the DRI line of products -->, [[Caldera UK|Caldera]]
| full_name               = File Allocation Table:<br />FAT12 (12-bit&nbsp;version),<br />FAT16 (16-bit&nbsp;versions),<br />FAT32 (32-bit&nbsp;version with 28&nbsp;bits used),<br />exFAT (64-bit&nbsp;versions)
| introduction_date       = 1977 ([[Standalone Disk BASIC-80]])<br />FAT12: August 1980 (SCP&nbsp;[[86-DOS|QDOS]])<br />FAT16: August 1984 (IBM&nbsp;[[PC DOS]] 3.0)<br />FAT16B: November 1987 ([[Compaq]] MS-DOS 3.31)<br />FAT32: August 1996 ([[Windows 95 OSR2]])<br />exFAT: November 2006 ([[Windows Embedded CE 6.0]])
| introduction_os         = <!-- merged with introduction_date -->
| partition_id            = [[Master Boot Record|MBR]]/[[Extended Boot Record|EBR]]:<br />[[FAT12]]:&nbsp;<code>{{abbr|0x|Values in C-notation for hexadecimal numbers}}[[Partition type#PID_01h|01]]</code> e.a.<br />[[FAT16]]:&nbsp;<code>{{abbr|0x|Values in C-notation for hexadecimal numbers}}[[Partition type#PID_04h|04]]</code><code>[[Partition type#PID_06h|0x06]]</code><code>[[Partition type#PID_0Eh|0x0E]]</code> e.a.<br />[[FAT32]]:&nbsp;<code>{{abbr|0x|Values in C-notation for hexadecimal numbers}}[[Partition type#PID_0Bh|0B]]</code><code>[[Partition type#PID_0Ch|0x0C]]</code> e.a.<br />[[exFAT]]:&nbsp;<code>{{abbr|0x|Values in C-notation for hexadecimal numbers}}[[Partition type#PID_07h|07]]</code> e.a.<br />[[Basic data partition|BDP]]:<br /><code>EBD0A0A2-B9E5-4433&shy;87C0-68B6B72699C7</code>
| directory_struct        = Table
| file_struct             = [[Linked list]]
| bad_blocks_struct       = Cluster tagging
| max_file_size           = 4,294,967,295 bytes (4&nbsp;<abbr title="gigabyte (1024&nbsp;MB or 1,048,576&nbsp;KB or 1,073,741,824&nbsp;bytes)">[[Gigabyte|GB]]</abbr> - 1)<!-- 2^32 - 1 --> with FAT16B and FAT32<ref name="GB4"/>
| max_files_no            = FAT12: 4,068 for 8&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">[[Kilobyte|KB]]</abbr> clusters <!-- 2^12 - 12 (reserved clusters) - 16 (number of 8 KB clusters for directory entries) --><br />FAT16: 65,460 for 32&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">KB</abbr> clusters <!-- 2^16 - 12 (reserved clusters) - 64 (number of 32 KB clusters for directory entries) --><br />FAT32: 268,173,300 for 32&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">KB</abbr> clusters <!-- 2^28 - 12 (reserved clusters) - 262144 (number of 32 KB clusters for directory entries) -->
| max_filename_size       = [[8.3 filename]], or 255 [[UCS-2]] characters when using [[Long filename|LFN]]
| max_volume_size         = FAT12: 32&nbsp;<abbr title="megabyte (1024&nbsp;KB or 1,048,576&nbsp;bytes)">[[Megabyte|MB]]</abbr><!-- with 2^16 sectors á 512 bytes, or with 8 KB clusters --> (256&nbsp;<abbr title="megabyte (1024&nbsp;KB or 1,048,576&nbsp;bytes)">MB</abbr> for 64&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">KB</abbr> clusters<!-- and EBPB -->)<br />FAT16: 2&nbsp;<abbr title="gigabyte (1024&nbsp;MB or 1,048,576&nbsp;KB or 1,073,741,824&nbsp;bytes)">GB</abbr> (4&nbsp;<abbr title="gigabyte (1024&nbsp;MB or 1,048,576&nbsp;KB or 1,073,741,824&nbsp;bytes)">GB</abbr> for 64&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">KB</abbr> clusters)<br />FAT32: 2&nbsp;<abbr title="terabyte (1024&nbsp;GB or 1,048,576&nbsp;MB or 1,073,741,824&nbsp;KB or 1,099,511,627,776&nbsp;bytes)">[[Terabyte|TB]]</abbr> (16&nbsp;<abbr title="terabyte (1024&nbsp;GB or 1,048,576&nbsp;MB or 1,073,741,824&nbsp;KB or 1,099,511,627,776&nbsp;bytes)">TB</abbr> for [[4Kn|4&nbsp;<abbr title="kilobyte (1024 or 2×512&nbsp;bytes)">KB</abbr> sectors]])
| dates_recorded          = Modified date/time, creation date/time (DOS 7.0 and higher only), access date (only available with [[ACCDATE (CONFIG.SYS directive)|ACCDATE]] enabled),<ref name="Microsoft_2006_ACCDATE"/> deletion date/time (only with DELWATCH 2<!-- with Novell DOS 7, Caldera OpenDOS 7.01, DR-DOS 7.02 and higher -->)
| date_range              = [[Epoch of 1980-01-01|1980-01-01]] to [[Year 2100 problem|2099-12-31]] ([[Year 2108 problem|2107-12-31]])
| date_resolution         = 2&nbsp;seconds for last modified time,<br />10&nbsp;ms for creation time,<br />1&nbsp;day for access date,<br />2&nbsp;seconds for deletion time
| forks_streams           = Not natively
| attributes              = [[#attributes|Read-only]], [[#attributes|Hidden]], [[#attributes|System]], [[#attributes|Volume]], [[#attributes|Directory]], [[#attributes|Archive]]
| file_system_permissions = FAT12/FAT16: File, directory and volume access rights for [[#access rights|Read]], [[#access rights|Write]], [[#access rights|Execute]], [[#access rights|Delete]] only with [[DR-DOS]], [[PalmDOS]], [[Novell DOS]], [[OpenDOS]], [[FlexOS]], [[IBM 4680 OS|4680&nbsp;OS]], [[IBM 4690 OS|4690&nbsp;OS]], [[Concurrent DOS]], [[Multiuser DOS]], [[Datapac System Manager|System Manager]], [[REAL/32]] (Execute right only with FlexOS, 4680&nbsp;OS, 4690&nbsp;OS; individual file / directory passwords not with FlexOS, 4680&nbsp;OS, 4690&nbsp;OS<!-- at least I could not find any user or programmer's documentation for it so far -->; [[#access rights|World]]/[[#access rights|Group]]/[[#access rights|Owner]] permission classes only with multiuser security loaded)<br />FAT32: Partial, only with DR-DOS, REAL/32 and 4690 OS<!-- version 2 and higher -->
| compression             = FAT12/FAT16: Per-volume, [[SuperStor]], [[Stacker (disk compression)|Stacker]], [[DoubleSpace]], [[DriveSpace]]<br />FAT32: No
| encryption              = FAT12/FAT16: Per-volume only with [[DR-DOS]]<br />FAT32: No
| data_deduplication      =
| copy_on_write           =
| OS                      =
}}
The '''FAT file system''' is a [[file system]] used on [[MS-DOS]] and [[Windows 9x|Windows 9x family of operating systems]].<ref name=":0">{{Cite web |last=Bhat |first=W. A. |date=2010 |title=Review of FAT data structure of FAT32 file system |s2cid=58178285 |language=en}}</ref> It continues to be used on [[mobile device]]s and [[embedded system]]s, and thus is a well suited file system for data exchange between computers and devices of almost any type and age from 1981<!-- 86-DOS 0.42+ and MS-DOS/PC DOS 1.x --> through the present.

== Structure ==
A FAT file system is composed of four regions:
{| class="wikitable"
|+ FAT file system regions, which includes four main regions
! Region
! Size in sectors
! Contents
!Notes
|-
| rowspan=3 | Reserved sectors
| rowspan=3 | (number of [[#RSVD SECTORS|reserved sectors]])
| [[#Boot Sector|Boot Sector]]
| rowspan="3" |The first reserved sector (logical sector 0) is the [[Boot sector|Boot Sector]] (also called ''[[Volume Boot Record]]'' or simply ''VBR''). It includes an area called the ''[[BIOS Parameter Block]]'' (''BPB'') 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]]'' (''DPB'') 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.<ref name="efi" />

For FAT32 file systems, the reserved sectors include a ''[[#FS Information Sector|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 (logical sector 0 only) 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.
|-
| [[#FS Information Sector|FS Information Sector]] (FAT32 only)
|-
| More reserved sectors (optional)
|-
| rowspan=2 | FAT Region
| rowspan=2 | (number of FATs) * (sectors per FAT)
| [[#FAT|File Allocation Table]] #1
| rowspan="2" |This typically contains two copies of the ''[[#FAT|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<!-- exact behaviour may depend on operating system, e.g. update copies only on close with transaction safe FAT -->, and on reads they are only used when errors occur in the first FAT. The first two clusters (cluster [[#CLUST 0|0]] and [[#CLUST 1|1]]) in the map contain special values.
|-
| File Allocation Table #2 ... (optional)
|-
| Root Directory Region
| (number of root entries * 32) / (bytes per sector)
| Root [[#Directory table|Directory]] (FAT12 and FAT16 only)
|This is a ''[[#Directory table|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
| (number of clusters) * (sectors per cluster)
| [[#DATA AREA|Data Region]] (for files and directories) ... (to end of partition or disk)
|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 (except for, where explicitly mentioned, for some entries on Atari ST boot sectors) and the FAT(s).<ref name="Haaf_1987_TOS"/> 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 (as noted in the boot record) can be larger than the number of sectors used by data (clusters × sectors per cluster), FATs (number of FATs × sectors per FAT), the root directory (n/a for FAT32), 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 device (computing)|storage devices]], such as [[floppy disk]]s, the [[Boot Sector]] ([[Volume Boot Record|VBR]]) is the first sector (logical sector 0 with physical CHS address 0/0/1 or LBA address 0). 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.<!-- DOS 1.x and some OEM MS-DOS 2.x did not use this format. -->

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|+Common structure of the Boot Sector used by most FAT versions for IBM compatible x86 machines since DOS 2.0
|-
! Byte offset
! Length (bytes)
! Contents
|-
| style="text-align:right;" | 0x000
| style="text-align:right;" | 3
| {{anchor|BSIBM_OFS_000h}}Jump instruction. If the boot sector has a valid signature residing in the [[#BSIBM_OFS_1FEh|last two bytes]] of the boot sector (tested by most boot loaders residing in the System BIOS or the MBR) 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 (non-executable) header. See [[Volume Boot Record]].

Since DOS 2.0, valid x86-bootable disks must start with either a short jump followed by a NOP ([[opstring]] sequence {{mono|0xEB 0x?? 0x90}}<ref name="Chappell_1994_DOS-Internals" /><ref name="Microsoft_1984_MS-DOS_3.1_Ref" /> as seen since DOS 3.0<ref group="nb" name="NB_MAGIC_EB" />&mdash;and on DOS 1.1<ref name="Sedory_2005_PCDOS10" /><ref name="Sedory_2005_PCDOS11" />) or a near jump ({{mono|0xE9 0x?? 0x??}}<ref name="Chappell_1994_DOS-Internals" /><ref name="Microsoft_1984_MS-DOS_3.1_Ref" /> as seen on most ([[Compaq]], [[TeleVideo PC DOS 2.11|TeleVideo]]) DOS 2.x formatted disks as well as on some ([[Epson]], [[Olivetti]]) DOS 3.1 disks). For backward compatibility MS-DOS, PC DOS<!-- at least MS-DOS/PC DOS 3.30 and higher --> and DR-DOS also accept a jump ({{mono|0x69 0x?? 0x??}})<ref name="Chappell_1994_DOS-Internals" /><ref name="Microsoft_1984_MS-DOS_3.1_Ref" /><ref name="Caldera_1997_DOSSRC_69h" /> on removable disks. On hard disks, DR&nbsp;DOS additionally accepts the swapped JMPS sequence starting with a NOP ({{mono|0x90 0xEB 0x??}}),<ref name="Caldera_1997_DOSSRC_69h" /> whereas MS-DOS/PC&nbsp;DOS do not. (See below for Atari ST compatibility.) The presence of one of these opstring patterns (in combination with a test for a valid media descriptor value at offset {{mono|[[#BPB20_OFS_0Ah|0x015]]}}) serves as indicator to DOS 3.3 and higher that some kind of BPB is present (although the exact size should not be determined from the jump target since some boot sectors contain private boot loader data following the BPB), while for DOS 1.x (and some DOS 3.0<!-- because of its partially invalid BPB alignment -->) volumes, they will have to fall back to the DOS 1.x method to detect the format via the media byte in the FAT (in logical [[#CLUST_0|sector 1]]<!-- cluster 0 happens to be located in logical sector 1 (physical CHS address 0/0/2, LBA address 1) only in this scenario, not in general -->).
|-
| style="text-align:right;" | 0x003
| style="text-align:right;" | 8
| {{anchor|BSIBM_OFS_003h}}OEM Name (padded with spaces {{mono|0x20}}). This value determines in which system the disk was formatted.

Although officially documented as free for OEM use, MS-DOS/PC&nbsp;DOS (since 3.1)<!-- not sure about 3.0 -->, Windows&nbsp;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&nbsp;DOS and OS/2 to not recognize the volume properly and cause data corruption on writes.<ref name="Paul_2002_OEM" /><ref name="Bass_1994_OEM" /><ref name="Williams_1992_MS-DOS-Reference" /> Common examples are "<code>[[PC DOS 3.3|IBM␠␠3.3]]</code>", "<code>[[MS-DOS 5.0|MSDOS5.0]]</code>", "<code>[[Windows 4.1|MSWIN4.1]]</code>"<!-- intentionally not directly [[Windows 98]] -->, "<code>[[PC DOS 7.1|IBM␠␠7.1]]</code>", "<code>mkdosfs␠</code>", and "<code>[[FreeDOS|FreeDOS␠]]</code>".

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 "<code>?????IHC</code>" signatures (a left-over from "<code>␠OGACIHC</code>" for "[[Windows Chicago|Chicago]]") even on a seemingly read-only disk access (such as a <code>DIR A:</code>) 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&nbsp;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 (which exists only for disks formatted on DOS 5.0 or later, and in [[Windows 9x]] after overwriting OEM label with <code>?????IHC</code> will report it as <code>0000-0000</code> or any other value stored in disk serial number field when using disk formatted on other system).<ref name="Paul_2004_OEM" /> 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 (e.g., NEWLDR offset {{mono|[[Master Boot Record#NEWLDR_OFS_018h|0x018]]}}).

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 "<code>Wang</code>". Similarly, the ROM BIOS of the [[Philips :YES]] will only boot from a disk if the first four characters of the OEM label are "<code>:YES</code>".

If, in an [[#EBPB32|FAT32 EBPB]], the signature at sector offset {{mono|[[#EBPB32_OFS_37h|0x042]]}} is {{mono|0x29}} 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 {{mono|[[#EBPB32_OFS_47h|0x052]]}}.

In a similar fashion, if this entry is set to "<code>[[exFAT|EXFAT␠␠␠]]</code>", it indicates the usage of an [[exFAT BPB]] located at sector offset {{mono|0x040}} to {{mono|0x077}}, whereas [[NTFS]] volumes use "<code>NTFS␠␠␠␠</code>"<ref name="Microsoft_2005_BB457122" /> to indicate an [[NTFS BPB]].
|- style="background:#F2F2F2"
| style="text-align:right;" | 0x00B
| style="text-align:right;" | varies
| ''[[#BPB|BIOS Parameter Block]]'' ([[#BPB20|13]], [[#BPB30|19]], [[#BPB32|21]] or [[#BPB331|25]] bytes), ''[[#EBPB|Extended BIOS Parameter Block]]'' (32 or 51 bytes) or ''[[#EBPB32|FAT32 Extended BIOS Parameter Block]]'' (60 or 79 bytes); size and contents varies between operating systems and versions, see below
|- style="background:#F2F2F2"
| style="text-align:right;" | varies
| style="text-align:right;" | varies
| File system and operating system specific boot code; often starts immediately behind [E]BPB, but sometimes additional "private" boot loader data is stored between the end of the [E]BPB and the start of the boot code; therefore the jump at offset {{mono|[[#BSIBM_OFS_000h|0x001]]}} cannot be used to reliably derive the exact [E]BPB format from.<!-- instead certain combinations of special values (0 in some entries) and the 0x28/0x29 signatures at 0x026 and 0x042 must be used, sometimes also special values in OEM label and media descriptor byte -->

{{anchor|BSIBM_OFS_1FAh}}(In conjunction with at least a [[#BPB331|DOS 3.31 BPB]] some [[GUID Partition Table|GPT]] boot loaders (like ''BootDuet'') use {{mono|0x1FA}}–{{mono|0x1FD}} to store the high 4&nbsp;bytes of the [[#BPB331_OFS_11h|hidden sector]]s for volumes located outside the first 2<sup>32</sup>-1&nbsp;sectors.<!-- Per http://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/source/16550b671aaf0f8c97b381cd8d17aa496755ce07:Migle_BootDuet_INSTALL.txt. --> Since this location may contain code or other data in other boot sectors, it may not be written to when {{mono|0x1F9}}–{{mono|0x1FD}} do not all contain zero.)
|- style="background:#F2F2F2"
| style="text-align:right;" | 0x1FD
| style="text-align:right;" | 1
| {{anchor|BSIBM_OFS_1FDh}}Physical drive number (only in DOS 3.2 to 3.31 boot sectors). With OS/2 1.0 and DOS 4.0, this entry moved to sector offset {{mono|0x024}} (at offset {{mono|[[#EBPB_OFS_19h|0x19]]}} in the [[#EBPB|EBPB]]). Most Microsoft and IBM boot sectors maintain values of {{mono|0x00}} at offset {{mono|0x1FC}} and {{mono|0x1FD}} ever since, although they are not part of the signature at {{mono|[[#BSIBM_OFS_1FEh|0x1FE]]}}.

If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset {{mono|[[Master Boot Record#NEWLDR_OFS_014h|0x014]]}}) 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 [[Volume Boot Record|VBR]] code ignores the DL value.
|-
| style="text-align:right;" | 0x1FE
| style="text-align:right;" | 2
| {{anchor|BSIBM_OFS_1FEh}}[[VBR boot signature|Boot sector signature]] ({{mono|0x55 0xAA}}).<ref name="efi" /><ref group="nb" name="NB_Magic_AA55" /> This signature indicates an IBM&nbsp;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 (but, e.g., not by the original IBM&nbsp;PC ROM-BIOS<ref name="IBM_1983_PC" />). This signature does not indicate a particular file system or operating system. Since this signature is not present on all FAT-formatted disks (e.g., not on DOS 1.x<ref name="Sedory_2005_PCDOS10" /><ref name="Sedory_2005_PCDOS11" /> or non-x86-bootable FAT volumes), operating systems must not rely on this signature to be present when logging in volumes (old issues of MS-DOS/PC&nbsp;DOS prior to 3.3 checked this signature, but newer issues<!-- at least 5.x-6.x issues --> as well as DR-DOS<!-- at least 7.xx issues --> do not). 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 ({{mono|0xF4 0xEB 0xFD}}) or issue an [[INT 19h]] and RETF ({{mono|0xCD 0x19 0xCB}}). These opstrings should not be used at sector offset {{mono|0x000}}, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use {{mono|0xEB 0xFE 0x90}} at sector offset {{mono|0x000}} 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 {{mono|0x1FE}} 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 ST]]s will assume a disk to be Atari [[68000]] bootable if the checksum over the 256 [[big-endian]] words of the boot sector equals {{mono|0x1234}}.<ref name="Jankowski_1992_Atari" /><ref group="nb" name="NB_Magic_1234" /> 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 (e.g., before or after the boot code area) can be used to ensure this condition is not met.

In rare cases, a reversed signature {{mono|0xAA 0x55}} has been observed on disk images. This can be the result of a faulty implementation in the formatting tool based on faulty documentation,<ref group="nb" name="NB_Magic_AA55" /> 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.<!-- Volumes with swapped signatures should not be treated as bootable on x86-compatible machines and should be mounted only with extra sanity checks in place. -->
|}

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|+FAT-formatted [[Atari ST]] floppies have a very similar boot sector layout
|-
! Byte offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x000
| style="text-align:right;"| 2
| {{anchor|BSST_OFS_000h}}Jump instruction. Original Atari ST boot sectors start with a [[68000]] BRA.S instruction ({{mono|0x60 0x??}}<!-- the jump target 0x?? is typically 0x38, but should not be relied upon -->).<ref name="Haaf_1987_TOS"/> For compatibility with PC operating systems, Atari ST formatted disks since [[Atari TOS|TOS]] 1.4 start with {{mono|0xE9 0x??}}<!-- AFAIK the 0x?? byte is typically set to 0x00, but this needs verification --> instead.<!-- NB. Not a very smart choice, 0xEB would have been better. TBD. Does TOS 1.4 directly enter the boot code at the corresponding offset, or are disks with the 0xEB signature not bootable at all on Ataris? -->
|-
| style="text-align:right;"| 0x002
| style="text-align:right;"| 6
| {{anchor|BSST_OFS_002h}}OEM Name (padded with spaces {{mono|0x20}}), e.g., "<code>Loader</code>" ({{mono|0x4C 0x6F 0x61 0x64 0x65 0x72}}) on volumes containing an Atari ST boot loader.<!-- AFAIK, the "Loader" signature is tested upon by the Atari ST BIOS, but this needs verification. The loader loads TOS.IMG. --> 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.
|-
| style="text-align:right;"| 0x008
| style="text-align:right;"| 3
| {{anchor|BSST_OFS_008h}}Disk serial number<ref name="Haaf_1987_TOS"/> (default: {{mono|0x00 0x00 0x00}}), used by Atari ST to detect a disk change. (Windows 9x Volume Tracker will always store "<code>IHC</code>" here on non-write-protected floppy disks; see above.) 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.
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 19
| ''[[#BPB30|DOS 3.0 BIOS Parameter Block]]'' ([[little-endian]] format)
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x01E
| style="text-align:right;"| varies
| Private boot sector data (mixed [[big-endian]] and [[little-endian]] format)
|- style="background:#F2F2F2"
| style="text-align:right;"| varies
| style="text-align:right;"| 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 (TOS.IMG<ref name="Haaf_1987_TOS"/>) fails, the code can return to the Atari ST BIOS with a 68000 RTS ([[opcode]] {{mono|0x4E75}} with [[big-endian]] byte sequence {{mono|0x4E 0x75}}<ref group="nb" name="NB_Magic_AA55"/><!-- 68000 is big-endian, whereas 8086 is little-endian, hence order of bytes is OK here -->) instruction and all registers unaltered.
|-
| style="text-align:right;"| 0x1FE
| style="text-align:right;"| 2
| {{anchor|BSST_OFS_1FEh}}Checksum. The 16-bit [[Modular sum|checksum]] over the 256 [[big-endian]] words of the 512 bytes boot sector including this word must match the [[Magic number (programming)|magic value]] {{mono|0x1234}} in order to indicate an Atari ST 68000 executable boot sector code.<ref name="Jankowski_1992_Atari"/> This checksum entry can be used to align the checksum accordingly.<ref group="nb" name="NB_Magic_1234"/>
If the logical sector size is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled.<ref name="Jankowski_1992_Atari"/>
Since some PC operating systems erroneously do not accept FAT formatted floppies if the {{mono|0x55 0xAA}}<ref group="nb" name="NB_Magic_AA55"/> signature is not present here, it is advisable to place the {{mono|0x55 0xAA}} in this place (and add an IBM compatible boot loader or stub) 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 {{mono|0x1234}}<ref group="nb" name="NB_Magic_1234"/> is not matched (unless the shared [[fat binary|fat code]] overlay would be both IBM PC and Atari ST executable at the same time).
|}

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|+FAT12-formatted [[MSX-DOS]] volumes have a very similar boot sector layout
|-
! Byte offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x000
| style="text-align:right;"| 3
| {{anchor|BSMSX_OFS_000h}}Dummy jump instruction (e.g., {{mono|0xEB 0xFE 0x90}}).
|-
| style="text-align:right;"| 0x003
| style="text-align:right;"| 8
| {{anchor|BSMSX_OFS_003h}}OEM Name (padded with spaces {{mono|0x20}}).<!-- TBD -->
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 19
| style="background:#F2F2F2" | ''[[#BPB30|DOS 3.0 BPB]]''
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x01E
| style="text-align:right;"| varies (2)
| {{anchor|BSMSX_OFS_01Eh}}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 (opstring {{mono|0x18 0xFE}} for JR {{mono|0x01E}}).
|-
| style="text-align:right;"| 0x020
| style="text-align:right;"| 6
| {{anchor|BSMSX_OFS_020h}} MSX-DOS 2 volume signature "<code>VOL_ID</code>".
|-
| style="text-align:right;"| 0x026
| style="text-align:right;"| 1
| {{anchor|BSMSX_OFS_026h}}MSX-DOS 2 undelete flag (default: {{mono|0x00}}<!-- which values? -->. If the "<code>VOL_ID</code>" signature is present at sector offset {{mono|[[#BSMSX_OFS_020h|0x020]]}}, this flag indicates, if the volume holds deleted files which can be undeleted (see offset {{mono|[[#DIR_OFS_0Ch|0x0C]]}} in directory entries).<!-- is this flag really only an indicator or does it enable this feature in the first place? -->
|-
| style="text-align:right;"| 0x027
| style="text-align:right;"| 4
| {{anchor|BSMSX_OFS_027h}}MSX-DOS 2 disk serial number (default: {{mono|0x00000000}}). If the "<code>VOL_ID</code>" signature is present at sector offset {{mono|[[#BSMSX_OFS_020h|0x020]]}}, MSX-DOS 2 stores a volume serial number here for media change detection.
|-
| style="text-align:right;"| 0x02B
| style="text-align:right;"| 5
| {{anchor|BSMSX_OFS_02Bh}}reserved
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x030
| style="text-align:right;"| varies (2)
| {{anchor|BSMSX_OFS_030h}}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 (opstring {{mono|0x18 0xFE}} for JR {{mono|0x030}}).
|-
| style="text-align:right;"| 0x1FE
| style="text-align:right;"| 2
| {{anchor|BSMSX_OFS_1FEh}}Signature<!-- TBD -->
|}

==== BIOS Parameter Block ====
{{anchor|BPB20}}

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|+Common structure of the first 25 bytes of the [[BIOS Parameter Block]] (BPB) used by FAT versions since DOS 2.0 (bytes at sector offset {{mono|0x00B}} to {{mono|0x017}} are stored since DOS 2.0, but not always used before DOS 3.2, values at {{mono|0x018}} to {{mono|0x01B}} are used since DOS 3.0)
|-
! Sector offset
! BPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 2
| {{anchor|BPB20_OFS_00h}}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<!-- limited by the size of a directory entry and the 16-bit sector BPB -->, or 64 bytes for more than 65,535 logical sectors<!-- limited by the size of the 32-bit EBPB/XBPB -->. The minimum practical value is 128.<!-- with old floppy disk formats and some RAM disks --> Some pre-DOS 3.31 OEM versions of DOS used logical sector sizes up to 8192 bytes for [[logical sectored FAT]]s. Atari ST [[GEMDOS]] supports logical sector sizes between 512 and 4096.<ref name="Jankowski_1992_Atari"/><!-- 8192 are theoretically supported as well, but are buggy. --> 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.<ref group="nb" name="NB_DRDOS_Logical-Sectoring"/>
The minimum logical sector size for standard FAT32 volumes is 512&nbsp;bytes, which can be reduced downto 128&nbsp;bytes<!-- due to the size of the FAT32 EBPB --> without support for the [[#FS Information Sector|FS Information Sector]].

Floppy drives and controllers use physical sector sizes of 128, 256, 512 and 1024 bytes (e.g., PC/AX). 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 drive]]s used sector sizes of 512<!-- 3,5-inch and 5.25-inch -->, 1024<!-- 5.25-inch only --> and 2048<!-- 3.5-inch only --> bytes. In 2005 some [[Seagate Technology|Seagate]] custom hard disks used sector sizes of 1024 bytes instead of the default 512 bytes.<ref name="Seagate"/> [[Advanced Format]] hard disks use 4096 bytes per sector (''[[4Kn]]'') since 2010, but will also be able to emulate 512 byte sectors (''[[512e]]'') 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.
|-
| style="text-align:right;"| 0x00D
| style="text-align:right;"| 0x02
| style="text-align:right;"| 1
| {{anchor|BPB20_OFS_02h}}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&nbsp;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<!-- at least since Windows 2000 --> 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 (or 64 KB) even for sector sizes larger than 512 bytes.<!-- this is down to the segment:offset memory allocation used by these real-mode systems. -->

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<!-- EDR-DOS 7.01.07 2004-08-30 and higher http://web.archive.org/web/20130314080925/http://www.drdosprojects.de/index.cgi/news.htm --> provide limited support for 128&nbsp;KB clusters with 512 bytes/sector using a sectors/cluster value of 0.

MS-DOS/PC&nbsp;DOS will hang on startup if this value is erroneously specified as 0.<ref name="Brown_2002_INTER61"/>{{rp|at=INT 21h AX=53h}}
|-
| style="text-align:right;"| 0x00E
| style="text-align:right;"| 0x03
| style="text-align:right;"| 2
| {{anchor|BPB20_OFS_03h}}Count of [[#RSVD_SECTORS|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 (to hold the extended boot sector, FS info sector and backup boot sectors).

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.
|-
| style="text-align:right;"| 0x010
| style="text-align:right;"| 0x05
| style="text-align:right;"| 1
| {{anchor|BPB20_OFS_05h}}Number of File Allocation Tables. Almost always 2; [[RAM disk]]s might use 1. Most versions of MS-DOS/PC&nbsp;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 ([[#CLUST_1|cluster 1]]) of the first FAT to determine the TFAT status.
|-
| style="text-align:right;"| 0x011
| style="text-align:right;"| 0x06
| style="text-align:right;"| 2
| {{anchor|BPB20_OFS_06h}}Maximum number of FAT12 or FAT16 root directory entries. 0 for FAT32, where the root directory is stored in ordinary data clusters; see offset {{mono|[[#EBPB32_OFS_21h|0x02C]]}} in FAT32 EBPBs.

A value of 0 without a [[#EBPB32|FAT32 EBPB]] (no signature {{mono|0x29}} or {{mono|0x28}} at offset {{mono|[[#EBPB32_OFS_37h|0x042]]}}) 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 [[#CLUST_1|cluster 1]] entry in the FAT.<ref name="BoynePollard_2010_BPB"/> This extension, however, is not supported by mainstream operating systems,<ref name="BoynePollard_2010_BPB"/> 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,<!-- more to be added here --> given that each [[#DIR|directory entry]] takes up 32 bytes. MS-DOS/PC&nbsp;DOS require this value to be a multiple of 16. The maximum value supported on floppy disks is 240,<ref name="Chappell_1994_DOS-Internals"/> the maximum value supported by MS-DOS/PC&nbsp;DOS on hard disks is 512.<ref name="Chappell_1994_DOS-Internals"/> DR-DOS supports booting off FAT12/FAT16 volumes, if the boot file is located in the first 2048 root directory entries.<!-- No limits on FAT32. -->
|-
| style="text-align:right;"| 0x013
| style="text-align:right;"| 0x08
| style="text-align:right;"| 2
| {{anchor|BPB20_OFS_08h}}Total logical sectors. 0 for FAT32. (If zero, use 4 byte value at offset {{mono|[[#BPB331_OFS_15h|0x020]]}})
|-
| style="text-align:right;"| 0x015
| style="text-align:right;"| 0x0A
| style="text-align:right;"| 1
| {{anchor|BPB20_OFS_0Ah|media}}Media descriptor (compare: [[#FATID|FAT ID]]):<ref name="msdosref"/><ref name="Microsoft_2003_KB75131"/><ref name="Microsoft_1987_DOS33Ref"/><ref group="nb" name="NB_MAGIC_EB"/>
;0xE5:
* 8-inch (200&nbsp;mm) single sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (250.25&nbsp;KB) (DR-DOS only<!-- at least 3.41-8.1, possibly earlier, but not 3.31 -->)
;0xED:
* 5.25-inch (130&nbsp;mm) double sided, 80 tracks per side, 9 sector, 720&nbsp;KB ([[Tandy 2000]] only)<ref name="Williams_1992_MS-DOS-Reference"/>
;0xEE:
* Designated for non-standard custom partitions (utilizing non-standard BPB formats or requiring special media access such as 48-/64-bit addressing); corresponds with {{mono|0xF8}}, but not recognized by unaware systems by design; value not required to be identical to FAT ID, never used as cluster end-of-chain marker (Reserved for DR-DOS)
;0xEF:
* Designated for non-standard custom [[superfloppy]] formats; corresponds with {{mono|0xF0}}, but not recognized by unaware systems by design; value not required to be identical to FAT ID, never used as cluster end-of-chain marker (Reserved for DR-DOS)
;0xF0<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/>
* 3.5-inch (90&nbsp;mm) double sided, 80 tracks per side, 18 or 36 sectors per track (1440&nbsp;KB, known as "1.44&nbsp;MB"; or 2880&nbsp;KB, known as "2.88&nbsp;MB").
* Designated for use with custom floppy and superfloppy formats where the geometry is defined in the BPB.
* Used also for other media types such as tapes.<ref name="AB"/>
;0xF4:
* Double density ([[Altos MS-DOS 2.11]] only)<ref name="Microsoft_2014_Altos"/>
;0xF5:
* Fixed disk, 4-sided, 12 sectors per track (1.95?&nbsp;MB) ([[Altos MS-DOS 2.11]] only)<ref name="Microsoft_2014_Altos"/>
;0xF8:
* Fixed disk (i.e., typically a partition on a hard disk). (since DOS 2.0)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/><ref name="Microsoft_2003_KB140418"/>
* Designated to be used for any partitioned fixed or removable media, where the geometry is defined in the BPB.
* 3.5-inch single sided, 80 tracks per side, 9 sectors per track (360 KB) (MS-DOS 3.1<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> and MSX-DOS)
* 5.25-inch double sided, 80 tracks per side, 9 sectors per track (720&nbsp;KB) ([[Sanyo]]&nbsp;55x DS-DOS 2.11 only)<ref name="Williams_1992_MS-DOS-Reference"/>
* Single sided ([[Altos MS-DOS 2.11]] only)<ref name="Microsoft_2014_Altos"/>
;0xF9<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/>
* 3.5-inch double sided, 80 tracks per side, 9 sectors per track (720&nbsp;KB) (since DOS 3.2)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>
* 3.5-inch double sided, 80 tracks per side, 18 sectors per track (1440&nbsp;KB) (DOS 3.2 only)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>
* 5.25-inch double sided, 80 tracks per side, 15 sectors per track (1200&nbsp;KB, known as "1.2&nbsp;MB") (since DOS 3.0)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>
* Single sided ([[Altos MS-DOS 2.11]] only)<ref name="Microsoft_2014_Altos"/>
;0xFA:
* 3.5-inch and 5.25-inch single sided, 80 tracks per side, 8 sectors per track (320&nbsp;KB)<!-- used on both 5.25-inch and 3.5-inch drives -->
* Used also for RAM disks and ROM disks (e.g., on [[Columbia Data Products]]<ref name="Lai_1992_DevDrv">{{cite book
|title=Writing MS-DOS Device Drivers
|first1=Robert S.
|last1=Lai
|last2=The Waite Group
|publisher=Addison Wesley
|edition=2nd
|year=1987
|isbn=0-201-60837-5
|url=https://archive.org/details/writingmsdosdevi00lair_0
}}</ref> and on [[HP&nbsp;200LX]]<!-- with 16 sectors per track -->)
* Hard disk ([[Tandy Corporation|Tandy]]&nbsp;MS-DOS only)
;0xFB:
* 3.5-inch and 5.25-inch double sided, 80 tracks per side, 8 sectors per track (640&nbsp;KB)<!-- used on both 5.25-inch and 3.5-inch drives -->
;0xFC:
* 5.25-inch single sided, 40 tracks per side, 9 sectors per track (180&nbsp;KB) (since DOS 2.0)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>
;0xFD:
* 5.25-inch double sided, 40 tracks per side, 9 sectors per track (360&nbsp;KB) (since DOS 2.0)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>
* 8-inch double sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (500.5&nbsp;KB)
* (8-inch double sided, (single<!-- 77/26/2/128 --> and) double density<!-- 77/8/2/1024 --> (DOS 1)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>)
;0xFE:
* 5.25-inch single sided, 40 tracks per side, 8 sectors per track (160&nbsp;KB) (since DOS 1.0)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/><ref name="Microsoft_2014_DEVDRIV"/>
* 8-inch single sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (250.25&nbsp;KB)<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/>
* 8-inch double sided, 77 tracks per side, 8 sectors per track, 1024 bytes per sector (1232&nbsp;KB)<ref name="Microsoft_2014_DEVDRIV"/>
* (8-inch single sided, (single<!-- 77/26/1/128 above --> and) double density<!-- 77/8/*1*/1024 --> (DOS 1)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/>)
;0xFF:
* 5.25-inch double sided, 40 tracks per side, 8 sectors per track (320&nbsp;KB) (since DOS 1.1)<ref name="Duncan_1988_MS-DOS_Encyclopedia"/><ref name="Microsoft_2014_DEVDRIV"/>
* Hard disk ([[Sanyo]]&nbsp;55x DS-DOS 2.11 only)<ref name="Williams_1992_MS-DOS-Reference"/>

This value must reflect the media descriptor stored (in the entry for [[#CLUST_0|cluster 0]]) in the first byte of each copy of the FAT.
Certain operating systems before DOS 3.2 ([[86-DOS]], [[MS-DOS]]/[[PC&nbsp;DOS]] 1.x and [[MSX-DOS]] version 1.0) 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 {{mono|0xF0}} since DOS 4.0.<ref name="Chappell_1994_DOS-Internals"/>

On removable drives, DR-DOS will assume the presence of a BPB if this value is greater or equal to {{mono|0xF0}},<ref name="Chappell_1994_DOS-Internals"/> whereas for fixed disks, it must be {{mono|0xF8}} 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 {{mono|0xF8}} or {{mono|0xFA}} to {{mono|0xFF}} MS-DOS/PC&nbsp;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.<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>
Values {{mono|0x00}} to {{mono|0xEF}} and {{mono|0xF1}} to {{mono|0xF7}} are reserved and must not be used.
|-
| style="text-align:right;"| 0x016
| style="text-align:right;"| 0x0B
| style="text-align:right;"| 2
| {{anchor|BPB20_OFS_0Bh}}Logical sectors per File Allocation Table for FAT12/FAT16.  FAT32 sets this to 0 and uses the 32-bit value at offset {{mono|[[#EBPB32_OFS_19h|0x024]]}} instead.
|}

{{anchor|BPB211|BPB30}}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.<ref name="Microsoft_2014_Altos"/><!-- as well as some versions of DOS 2.13 --> MS-DOS 3.10 still supported the DOS 2.0 format, but could use the DOS 3.0 format as well.

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|-
! Sector offset
! BPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 13
| style="background:#F2F2F2" | ''[[#BPB20|DOS 2.0 BPB]]''
|-
| style="text-align:right;"| 0x018
| style="text-align:right;"| 0x0D
| style="text-align:right;"| 2
| {{anchor|BPB30_OFS_0Dh}}Physical sectors per track for disks with [[INT 13h]] CHS geometry,<ref name="efi" /> e.g., 15 for a "1.20&nbsp;MB" (1200&nbsp;KB) floppy.

A zero entry indicates that this entry is reserved, but not used.<!-- according to MS-DOS 3.21 OAK README.TXT -->
|-
| style="text-align:right;"| 0x01A
| style="text-align:right;"| 0x0F
| style="text-align:right;"| 2
| {{anchor|BPB30_OFS_0Fh}}Number of heads for disks with INT&nbsp;13h CHS geometry,<ref name="efi" /> e.g., 2 for a double sided floppy.

A bug in all versions of MS-DOS/PC DOS up to including 7.10<!-- not sure if it was fixed with 8.0, but it still existed in 7.1 of 87 SE the least --> 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.<!-- according to MS-DOS 3.21 OAK README.TXT -->
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x01C
| style="text-align:right;"| 0x11
| style="text-align:right;"| 2
| {{anchor|BPB30_OFS_11h}}Count of hidden<!-- physical? --> 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 {{mono|[[#BPB331_OFS_11h|0x01C]]}} in BPBs since DOS 3.31.
It must not be used if the logical sectors entry at offset {{mono|[[#BPB20_OFS_08h|0x013]]}} is zero.<!-- as this would indicate a DOS 3.31 BPB format -->
|}

{{anchor|BPB32}}DOS 3.2 BPB:

Officially, MS-DOS 3.20 still used the DOS 3.0 format, but <code>[[SYS (command)|SYS]]</code> and <code>[[FORMAT (command)|FORMAT]]</code> were adapted to support a 6 bytes longer format already (of which not all entries were used).

{| class="wikitable" width="100%"
|-
! Sector offset
! BPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 19
| style="background:#F2F2F2" | ''[[#BPB30|DOS 3.0 BPB]]''
|- style="background:#F2F2F2"
| style="text-align:right;"| 0x01E
| style="text-align:right;"| 0x13
| style="text-align:right;"| 2
| {{anchor|BPB32_OFS_13h}}Total logical sectors including hidden sectors. This DOS 3.2 entry is incompatible with a similar entry at offset {{mono|[[#BPB331_OFS_15h|0x020]]}} in BPBs since DOS 3.31.
It must not be used if the logical sectors entry at offset {{mono|[[#BPB20_OFS_08h|0x013]]}} is zero.<!-- as this would indicate a DOS 3.31 BPB format -->
|}

{{anchor|BPB331}}DOS 3.31 BPB:

Officially introduced with DOS 3.31 and not used by DOS 3.2, some DOS 3.2 utilities<!-- FORMAT, SYS and SCOPE --> 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 {{mono|[[#BPB20_OFS_08h|0x013]]}} is zero<!-- according to MS-DOS 3.21 OAK README.TXT -->.

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|-
! Sector offset
! BPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 13
| style="background:#F2F2F2" | ''[[#BPB20|DOS 2.0 BPB]]''
|-
| style="text-align:right;"| 0x018
| style="text-align:right;"| 0x0D
| style="text-align:right;"| 2
| {{anchor|BPB331_OFS_0Dh}}Physical sectors per track for disks with [[INT 13h]] CHS geometry,<ref name="efi" /> e.g., 18 for a "1.44&nbsp;MB" (1440&nbsp;KB) floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available [[#BPB30_OFS_0Dh|since DOS 3.0]].

A zero entry indicates that this entry is reserved, but not used.<!-- according to MS-DOS 3.21 OAK README.TXT --> 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.
|-
| style="text-align:right;"| 0x01A
| style="text-align:right;"| 0x0F
| style="text-align:right;"| 2
| {{anchor|BPB331_OFS_0Fh}}Number of heads for disks with INT&nbsp;13h CHS geometry,<ref name="efi" /> e.g., 2 for a double sided floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available [[#BPB30_OFS_0Fh|since DOS 3.0]].

A bug in all versions of MS-DOS/PC DOS up to including 7.10<!-- not sure if it was fixed with 8.0, but it still existed in 7.1 of 87 SE the least --> 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.<!-- according to MS-DOS 3.21 OAK README.TXT --> 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.
|-
| style="text-align:right;"| 0x01C
| style="text-align:right;"| 0x11
| style="text-align:right;"| 4
| {{anchor|BPB331_OFS_11h}}Count of hidden<!-- physical? --> sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned.<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/> This DOS 3.31 entry is incompatible with a similar entry at offset {{mono|[[#BPB30_OFS_11h|0x01C]]}} 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 {{mono|[[#BPB20_OFS_08h|0x013]]}} is zero.

If this belongs to an [[Advanced Active Partition]] (AAP) 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 {{mono|[[Master Boot Record#MBRAAP_OFS_1B6h|0x1B6]]}} in the AAP or NEWLDR MBR<!-- under PTS-DOS 6.60+ or DR-DOS 7.07) -->, so that it becomes possible to boot the operating system from [[Extended Boot Record|EBR]]s.

(Some [[GUID Partition Table|GPT]] boot loaders (like ''BootDuet'') use boot sector offsets [[#BSIBM_OFS_1FAh|{{mono|0x1FA}}–{{mono|0x1FD}}]] to store the high 4&nbsp;bytes of a 64-bit hidden sectors value for volumes located outside the first 2<sup>32</sup>−1&nbsp;sectors.<!-- http://gitorious.org/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/source/16550b671aaf0f8c97b381cd8d17aa496755ce07:Migle_BootDuet_INSTALL.txt. -->)
|-
| style="text-align:right;"| 0x020
| style="text-align:right;"| 0x15
| style="text-align:right;"| 4
| {{anchor|BPB331_OFS_15h}}Total logical sectors (if greater than 65535; otherwise, see offset {{mono|[[#BPB20_OFS_08h|0x013]]}}). This DOS 3.31 entry is incompatible with a similar entry at offset {{mono|[[#BPB32_OFS_13h|0x01E]]}} in DOS 3.2-3.3 BPBs.<!-- Reportedly this was also supported by the earlier multitasking European MS-DOS 4.0, although probably without FAT16B support. --> Officially, it must be used only if the logical sectors entry at offset {{mono|[[#BPB20_OFS_08h|0x013]]}} is zero, but some operating systems (some old versions of DR DOS) use this entry also for smaller disks.<!-- making BPB format detection difficult -->

For partitioned media, if this and the entry at {{mono|[[#BPB20_OFS_08h|0x013]]}} are both 0 (as seen on some DOS 3.x FAT16 volumes), many operating systems (including MS-DOS/PC DOS) will retrieve the value from the corresponding partition's entry (at offset {{mono|[[Master boot record#PTE_OFS_Ch|0xC]]}}) in the [[Master Boot Record|MBR]] instead.

If both of these entries are 0 on volumes using a {{mono|[[#EBPB32|FAT32 EBPB]]}} with signature {{mono|0x29}}, values exceeding the 4,294,967,295 (2<sup>32</sup>−1) limit (f.e. some [[DR-DOS]] volumes with 32-bit cluster entries) can use a 64-bit entry at offset {{mono|[[#EBPB32_OFS_47h|0x052]]}} instead.
|}

A simple formula translates a volume's given cluster number <code>CN</code> to a logical sector number <code>LSN</code>:<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/>

# Determine (once) <code><abbr title="Size of System Area">SSA</abbr>=<abbr title="Reserved Sector Count">RSC</abbr>+<abbr title="number of FATs">FN</abbr>×<abbr title="Sectors per FAT">SF</abbr>+ceil((32×<abbr title="Root Directory Entries">RDE</abbr>)/<abbr title="Sector Size">SS</abbr>)</code>, where the reserved sector count <code>RSC</code> is stored at offset {{mono|0x00E}}, the number of FATs<code>FN</code> at offset {{mono|0x010}}, the sectors per FAT <code>SF</code> at offset {{mono|0x016}} (FAT12/FAT16) or {{mono|0x024}} (FAT32), the root directory entries <code>RDE</code> at offset {{mono|0x011}}, the sector size <code>SS</code> at offset {{mono|0x00B}}, and <code>ceil(x)</code> rounds up to a whole number.
# Determine <code><abbr title="Logical Sector Number">LSN</abbr>=<abbr title="Size of System Area">SSA</abbr>+(<abbr title="Cluster number">CN</abbr>−2)×<abbr title="Sectors per Cluster">SC</abbr></code>, where the sectors per cluster <code>SC</code> are stored at offset {{mono|0x00D}}.

On unpartitioned media the volume's number of hidden sectors is zero and therefore <code>LSN</code> and <code>LBA</code> 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 <code>[[Cylinder-head-sector|CHS]]</code> addresses and <code>LSNs</code> as well:

<code><abbr title="Logical Sector Number">LSN</abbr>=<abbr title="Sectors Per Track">SPT</abbr>×(<abbr title="Head Number">HN</abbr>+(<abbr title="Number Of Sides">NOS</abbr>×<abbr title="Track Number">TN</abbr>))+<abbr title="Sector Number">SN</abbr>−1</code>, where the sectors per track <code>SPT</code> are stored at offset {{mono|0x018}}, and the number of sides <code>NOS</code> at offset {{mono|0x01A}}. Track number <code>TN</code>, head number <code>HN</code>, and sector number <code>SN</code> correspond to [[Cylinder-head-sector]]: the formula gives the known CHS to [[Logical Block Addressing|LBA]] translation.

==== Extended BIOS Parameter Block ====
<span id="EBPB"></span>Further structure used by FAT12 and FAT16 since OS/2 1.0 and DOS 4.0, also known as [[Extended BIOS Parameter Block]] (EBPB) (bytes below sector offset {{mono|0x024}} are the same as for the DOS 3.31 BPB):

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|-
! Sector offset
! EBPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 25
| style="background:#F2F2F2" | ''[[#BPB331|DOS 3.31 BPB]]''
|-
| style="text-align:right;"| 0x024
| style="text-align:right;"| 0x19
| style="text-align:right;"| 1
| {{anchor|EBPB_OFS_19h}}Physical drive number ({{mono|0x00}} for (first) removable media, {{mono|0x80}} for (first) fixed disk as per [[INT 13h]]). Allowed values for possible physical drives depending on BIOS are {{mono|0x00}}-{{mono|0x7E}} and {{mono|0x80}}-{{mono|0xFE}}. Values {{mono|0x7F}} and {{mono|0xFF}} are reserved for internal purposes such as remote or ROM boot and should never occur on disk.<!-- DR-DOS uses 7Fh for remote and FFh for ROM disks, MS-DOS/PC&nbsp;DOS uses 7Fh for ROM. --> Some boot loaders such as the MS-DOS<!-- at least 5.0 and higher -->/PC&nbsp;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 [[Volume boot record#IN|underlying boot loader]] (e.g., with many BIOSes and MBRs).<!-- NB. Not all BIOSes and MBRs provide a proper DL value, though, so there should be some validity check or "fall-back" when attempting to use DL. --> The entry is sometimes changed by the [[SYS (command)|SYS]] command<!-- DR-DOS 7.07 SYS 1.66 does so using its /O[:nnn] parameter: without the parameter, the DR-DOS boot sector will use DL, with /O, the boot sector will use the entry at offset {{mono|0x024}} (with default values {{mono|0x00}} or {{mono|0x80}} stored there by SYS, with /O:nnn the user can specify the value to be stored at {{mono|0x24}} as well. --><!-- On FAT12/FAT16, FreeDOS uses DL only if this BPB entry holds FFh, on FAT32 it always uses DL. --> 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 (only) in DOS 3.2 to 3.31 boot sectors at sector offset {{mono|[[#BSIBM_OFS_1FDh|0x1FD]]}}.

If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset {{mono|[[Master Boot Record#NEWLDR_OFS_014h|0x014]]}}) 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 [[Volume Boot Record|VBR]] code ignores the DL value.
|-
| style="text-align:right;"| 0x025
| style="text-align:right;"| 0x1A
| style="text-align:right;"| 1
| {{anchor|EBPB_OFS_1Ah}}Reserved;
* In some MS-DOS/PC DOS boot code used as a scratchpad for the [[INT 13h]] current head high byte for the assumed 16-bit word at offset {{mono|[[#EBPB_OFS_19h|0x024]]}}.<!-- Details to be added --> Some DR-DOS FAT12/FAT16 boot sectors use this entry as a scratchpad as well, but for different purposes.<!-- and it may be part of the interface with the loaded boot file -->
* [[VGA-Copy]] stores a [[Cyclic redundancy check|CRC]] over the system's ROM-BIOS in this location.<!-- purpose unknown -->
* Some boot managers use this entry to communicate the desired drive letter under which the volume should occur to operating systems such as OS/2 by setting bit 7 and specifying the drive number in bits 6-0 (C: = value 0, D: = value 1, ...). Since this normally affects the in-memory image of the boot sector only, this does not cause compatibility problems with other uses;
* In Windows NT used for [[CHKDSK]] flags (bits 7-2 always cleared, bit 1: disk I/O errors encountered, possible bad sectors, run surface scan on next boot, bit 0: volume is "dirty" and was not properly unmounted before shutdown, run CHKDSK on next boot).<ref name="Microsoft_2003_KB140418"/> Should be set to 0 by formatting tools.<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/> See also: Bitflags in the [[#CLUST_1|second cluster entry]] in the FAT.
|-
| style="text-align:right;"| 0x026
| style="text-align:right;"| 0x1B
| style="text-align:right;"| 1
| {{anchor|EBPB_OFS_1Bh}}Extended boot signature. (Should be {{mono|0x29}}<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/><ref name="msdosref"/> to indicate that an EBPB with the following 3 entries exists (since OS/2 1.2 and DOS 4.0). Can be {{mono|0x28}} on some OS/2&nbsp;1.0-1.1 and PC&nbsp;DOS 3.4 disks indicating an earlier form of the EBPB format with only the serial number following. MS-DOS/PC&nbsp;DOS 4.0 and higher, OS/2 1.2 and higher as well as the Windows NT family recognize both signatures accordingly.)
|-
| style="text-align:right;"| 0x027
| style="text-align:right;"| 0x1C
| style="text-align:right;"| 4
| {{anchor|EBPB_OFS_1Ch}}Volume ID (serial number)
Typically the serial number "xxxx-xxxx" is created by a 16-bit addition of both DX values returned by INT 21h/AH=2Ah (get system date)<ref group="nb" name="NB_INT21_DATETIME"/> and INT 21h/AH=2Ch (get system time)<ref group="nb" name="NB_INT21_DATETIME"/> 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 <code>/#</code> 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.
|-
| style="background:#f2f2f2; text-align:right;"| 0x02B
| style="background:#f2f2f2; text-align:right;"| 0x20
| style="background:#f2f2f2; text-align:right;"| 11
| style="background:#F2F2F2" | {{anchor|EBPB_OFS_20h}}Partition Volume Label, padded with blanks ({{mono|0x20}}), e.g., "<code>NO␠NAME␠␠␠␠</code>" Software changing the [[#DIR_OFS_0Bh|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 {{mono|[[#EBPB_OFS_1Bh|0x026]]}} is set to {{mono|0x28}}.

This area was used by boot sectors of DOS 3.2 to 3.3 to store a private copy of the [[Disk Parameter Table]] (DPT) instead of using the INT&nbsp;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.
|-
| style="background:#f2f2f2; text-align:right;"| 0x036
| style="background:#f2f2f2; text-align:right;"| 0x2B
| style="background:#f2f2f2; text-align:right;"| 8
| style="background:#F2F2F2" | {{anchor|EBPB_OFS_2Bh}}File system type, padded with blanks ({{mono|0x20}}), e.g., "<code>FAT12␠␠␠</code>", "<code>FAT16␠␠␠</code>", "<code>FAT␠␠␠␠␠</code>"
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 <!-- normal -->MS-DOS 4.0 and higher.

Not available if the signature at {{mono|[[#EBPB_OFS_1Bh|0x026]]}} is set to {{mono|0x28}}.
|}

==== FAT32 Extended BIOS Parameter Block ====
<span id="EBPB32"></span>In essence FAT32 inserts 28 bytes into the EBPB, followed by the remaining 26 (or sometimes only 7) [[#EBPB|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,<ref group="nb" name="NB_Hybrid_Disk"/> operating systems should be prepared to cope with these hybrid forms.

{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%"
|-
! Sector offset
! FAT32 EBPB offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x00B
| style="text-align:right;"| 0x00
| style="text-align:right;"| 25
| style="background:#F2F2F2" | ''[[#BPB331|DOS 3.31 BPB]]''
|-
| style="text-align:right;"| 0x024
| style="text-align:right;"| 0x19
| style="text-align:right;"| 4
| {{anchor|EBPB32_OFS_19h}}Logical sectors per file allocation table (corresponds with the old entry at [[#BPB20_OFS_0Bh|offset 0x0B in the DOS 2.0 BPB]]).

The byte at offset {{mono|[[#EBPB_OFS_1Bh|0x026]]}} in this entry should never become {{mono|0x28}} or {{mono|0x29}} in order to avoid any misinterpretation with the EBPB format under non-FAT32 aware operating systems.

Fortunately, under normal circumstances (sector size of 512 bytes), 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(268435446 / 128) = 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.
|-
| style="text-align:right;"| 0x028
| style="text-align:right;"| 0x1D
| style="text-align:right;"| 2
| {{anchor|EBPB32_OFS_1Dh}}Drive description / mirroring flags (bits 3-0: zero-based number of active FAT, if bit 7 set.<ref name="efi"/> If bit 7 is clear, all FATs are mirrored as usual. Other bits reserved and should be 0.)

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 {{mono|0110:1111b}} (low-case letter 'o', bit 13 set for CHS access) or {{mono|0100:1111b}} (upper-case letter 'O', bit 13 cleared for LBA access). The byte is also used for the second character in a potential "No␠IBMBIO␠␠COM" error message (see offset {{mono|[[#EBPB32_OFS_29h|0x034]]}}), displayed either in mixed or upper case, thereby indicating which access type failed). Formatting tools or non-DR SYS-type tools may clear these bits, but other disk tools should leave bits 15-8 unchanged.<!-- there are also DR-DOS 7.07 FAT32 boot sectors which support either LBA or CHS only, choosable by SYS options /LBAONLY or /CHSONLY. Those variants don't use bits 15-8. -->
|-
| style="text-align:right;"| 0x02A
| style="text-align:right;"| 0x1F
| style="text-align:right;"| 2
| {{anchor|EBPB32_OFS_1Fh}}Version (defined as 0.0). The high byte of the version number is stored at offset {{mono|0x02B}}, and the low byte at offset {{mono|0x02A}}.<ref name="efi"/> FAT32 implementations should refuse to mount volumes with version numbers unknown by them.
|-
| style="text-align:right;"| 0x02C
| style="text-align:right;"| 0x21
| style="text-align:right;"| 4
| {{anchor|EBPB32_OFS_21h}}Cluster number of root directory start, typically 2 (first cluster<ref name="two"/>) if it contains no bad sector. (Microsoft's FAT32 implementation imposes an artificial limit of 65,535 entries per directory, whilst many third-party implementations do not.)

A cluster value of [[#CLUST_0|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;<!-- to be detailed --> see offset {{mono|[[#BPB20_OFS_06h|0x011]]}}.
|-
| style="text-align:right;"| 0x030
| style="text-align:right;"| 0x25
| style="text-align:right;"| 2
| {{anchor|EBPB32_OFS_25h}}Logical sector number of [[#FS Information Sector|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 {{mono|0xFFFF}}<ref name="Brown_2002_INTER61"/><!-- also c't 5/1997 --> (or {{mono|0x0000}}) 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 {{Citation needed|date=April 2017}}, 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.<!-- it is not clear how MS operating systems behave in this situation --> Without a FS Information Sector, the minimum allowed [[#BPB20_OFS_00h|logical sector size]] of FAT32 volumes can be reduced downto 128&nbsp;bytes for special purposes.
|-
| style="text-align:right;"| 0x032
| style="text-align:right;"| 0x27
| style="text-align:right;"| 2
| {{anchor|EBPB32_OFS_27h}}First logical sector number of a copy of the three FAT32 boot sectors, typically 6.<ref name="efi"/><!-- The 6 is hardwired in NT MBR for FAT32 partition types 0x0B and 0x0C, but there are exactly three FAT32 boot sectors for sector length 512, not one, not six; see reference. -->
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 {{mono|0x0000}}<ref name="efi"/> (and/or {{mono|0xFFFF}}<ref name="Brown_2002_INTER61"/><!-- also c't 5/1997 -->) are reserved and indicate that no backup sector is available.
|-
| style="text-align:right;"| 0x034
| style="text-align:right;"| 0x29
| style="text-align:right;"| 12
| {{anchor|EBPB32_OFS_29h}}Reserved (may be changed to format filler byte {{mono|0xF6}}<ref group="nb" name="NB_Format_Wipe"/> as an artifact by MS-DOS <code>[[FDISK]]</code>, must be initialized to 0 by formatting tools, but must not be changed by file system implementations or disk tools later on.)

DR-DOS 7.07 FAT32 boot sectors use these 12 bytes to store the filename of the "<code>[[IBMBIO.COM|IBMBIO␠␠COM]]</code>"<ref group="nb" name="NB_DRDOS_BIOS-Name"/> file to be loaded (up to the first 29,696 bytes or the actual file size, whatever is smaller<!-- all BIOS files up to 7.05 are smaller, and larger files must contain a tertiary loader stub on their own in order to load the remainder of the file into memory themselves -->) and executed by the boot sector, followed by a terminating NUL ({{mono|0x00}}) character. This is also part of an error message, indicating the actual boot file name and access method (see offset {{mono|[[#EBPB32_OFS_1Dh|0x028]]}}).
|-
| style="text-align:right;"| 0x040
| style="text-align:right;"| 0x35
| style="text-align:right;"| 1
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_35h}}Cf. {{mono|[[#EBPB_OFS_19h|0x024]]}} for FAT12/FAT16 (Physical Drive Number)

[[exFAT BPB]]s are located at sector offset {{mono|0x040}} to {{mono|0x077}}, overlapping all the remaining entries of a standard FAT32 EBPB including this one. They can be detected via their OEM label signature "<code>[[exFAT|EXFAT␠␠␠]]</code>" at sector offset {{mono|[[#BSIBM_OFS_003h|0x003]]}}. In this case, the bytes at {{mono|0x00B}} to {{mono|0x03F}} are normally set to {{mono|0x00}}.
|-
| style="text-align:right;"| 0x041
| style="text-align:right;"| 0x36
| style="text-align:right;"| 1
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_36h}}Cf. {{mono|[[#EBPB_OFS_1Ah|0x025]]}} for FAT12/FAT16 (Used for various purposes; see FAT12/FAT16)

May hold format filler byte {{mono|0xF6}}<ref group="nb" name="NB_Format_Wipe"/> artifacts after partitioning with MS-DOS FDISK, but not yet formatted.
|-
| style="text-align:right;"| 0x042
| style="text-align:right;"| 0x37
| style="text-align:right;"| 1
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_37h}}Cf. {{mono|[[#EBPB_OFS_1Bh|0x026]]}} for FAT12/FAT16 (Extended boot signature, {{mono|0x29}})

Most FAT32 file system implementations do not support an alternative signature of {{mono|0x28}}<ref name="Microsoft_2005_BB457122"/> to indicate a shortened form of the FAT32 EBPB with only the serial number following (and no Volume Label and File system type entries), but since these 19 mostly unused bytes might serve different purposes in some scenarios, implementations should accept {{mono|0x28}} 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.
|-
| style="text-align:right;"| 0x043
| style="text-align:right;"| 0x38
| style="text-align:right;"| 4
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_38h}}Cf. {{mono|[[#EBPB_OFS_1Ch|0x027]]}} for FAT12/FAT16 (Volume ID)
|-
| style="text-align:right;"| 0x047
| style="text-align:right;"| 0x3C
| style="text-align:right;"| 11
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_3Ch}}Cf. {{mono|[[#EBPB_OFS_20h|0x02B]]}} for FAT12/FAT16 (Volume Label)

Not available if the signature at offset {{mono|[[#EBPB32_OFS_37h|0x042]]}} is set to {{mono|0x28}}.
|-
| style="text-align:right;"| 0x052
| style="text-align:right;"| 0x47
| style="text-align:right;"| 8
| style="background:#F2F2F2" | {{anchor|EBPB32_OFS_47h}}Cf. {{mono|[[#EBPB_OFS_2Bh|0x036]]}} for FAT12/FAT16 (File system type, padded with blanks ({{mono|0x20}}), e.g., "<code>FAT32␠␠␠</code>").
Not available if the signature at {{mono|[[#EBPB32_OFS_37h|0x042]]}} is set to {{mono|0x28}}.

If both total logical sectors entries at offset {{mono|[[#BPB331_OFS_15h|0x020]]}} and {{mono|[[#BPB20_OFS_08h|0x013]]}} are 0 on volumes using a [[#EBPB32|FAT32 EBPB]] with signature {{mono|0x29}}, volumes with more than 4,294,967,295 (2<sup>32</sup>-1) sectors (f.e. some [[DR-DOS]] volumes with 32-bit cluster entries) can<!-- under some conditions --> use this entry as ''64-bit total logical sectors'' entry instead.<!-- of which only up to 48 bits are used for sector sizes larger or equal to 512 bytes --> In this case, the OEM label at sector offset {{mono|[[#BSIBM_OFS_003h|0x003]]}} may be retrieved as new-style ''file system type'' instead.<!-- for read, not sure about write -->
|}

==== Exceptions ====
Versions of DOS before 3.2 totally or partially relied on the [[#media|media descriptor byte]] in the BPB or the [[#FATID|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.<ref group="nb" name="NB_MAGIC_EB"/>

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 (vs. 40 track) format, bit 1 cleared to indicate a 9 sector (vs. 8 sector) format, and bit 0 cleared to indicate a single-sided (vs. double-sided) format,<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> 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.

<!-- more details to be sorted out, split into two tables, one for standard formats, one for exotic formats -->
<!-- 86-DOS 8" formats -->
<!-- HP 150, 3.5&quot;, 270KB, SS -->
<!-- Tandy 2000, 5.25&quot;, 720KB, DS, 96tpi -->
<!-- DEC Rainbow, 5.25&quot;, 400KB, SS, 96tpi -->
<!-- Victor 9000 / Sirius 1, 5.25&quot;, 1.2MB, DS, 96tpi, multi-speed -->
<!-- various Apricot formats, see below -->
<!-- 3mode formats to be added -->
<!-- FIDO 8" double-density format -->
<!-- 2x IBM Displaywriter format 8" http://hackipedia.org/Physical%20media/Floppy%20disk/MS-DOS/MSDOS%201.xx%20-%202.xx%20Disk%20formats%20T.%20Jennings%2019%20Aug%2083%2c%20%288%27%20formats%20updated%2017%20Aug%29.ascii.txt.utf-8.txt -->
<!-- IBM 320KB 8-sectors 2-sided format sectors/FAT oddity: 1 or 2? -->
<!-- alternative sector ordering in DOS 1.1 vs. DOS 2.0+ on 2-sided floppies -->
{{anchor|FATID}}
<div style="overflow-x:auto">
{| class="wikitable sortable mw-collapsible mw-collapsed" width="100%" style="margin:0"
|-
! {{rh}} | FAT ID (compare with [[#media|media ID]] at BPB offset {{mono|[[#BPB20_OFS_0Ah|0x0A]]}})<ref name="Microsoft_2003_KB75131"/><ref name="Microsoft_1987_DOS33Ref"/> 
| colspan="2" style="background:#F2F2F2;" | {{mono|'''0xFF'''}} || colspan="3" style="background:#F2F2F2;" | {{mono|'''0xFE'''}} || colspan="3" style="background:#F2F2F2;" | {{mono|'''0xFD'''}} || style="background:#F2F2F2;" | {{mono|'''0xFC'''}} || {{mono|0xFB}} || {{mono|0xFA}} || colspan="3" style="background:#F2F2F2;" | {{mono|'''0xF9'''}} || colspan="3" | {{mono|0xF8}} || colspan="2" style="background:#F2F2F2;" | {{mono|'''0xF0'''}} || {{mono|0xED}} || {{mono|0xE5}}
|-
! {{rh}} | Size 
| 8" || style="background:#F2F2F2;" | 5.25" || style="background:#F2F2F2;" | 8" || style="background:#F2F2F2;" | 8" || style="background:#F2F2F2;" | 5.25" || 8" || style="background:#F2F2F2;" | 8" || style="background:#F2F2F2;" | 5.25" || style="background:#F2F2F2;" | 5.25" || 5.25" / 3.5" || 5.25" / 3.5" || style="background:#F2F2F2;" | 5.25" || style="background:#F2F2F2;" | 3.5" || 3.5" || 5.25" || 5.25" / 3.5" || 3.5" || style="background:#F2F2F2;" | 3.5" || style="background:#F2F2F2;" | 3.5" || 5.25" || 8"
|-
! {{rh}} | Density 
| {{dunno}} || style="background:#F2F2F2;" | DD 48tpi || style="background:#F2F2F2;" | SD || style="background:#F2F2F2;" | DD || style="background:#F2F2F2;" | DD 48tpi || SD || style="background:#F2F2F2;" | SD || style="background:#F2F2F2;" | DD 48tpi || style="background:#F2F2F2;" | DD 48tpi || {{dunno}}<!-- QD or DD --> || {{dunno}}<!-- QD or DD --> || style="background:#F2F2F2;" | HD 96tpi || style="background:#F2F2F2;" | DD 135tpi || HD 135tpi || QD 96tpi || {{dunno}}<!-- QD or DD --> || DD || style="background:#F2F2F2;" | HD 135tpi || style="background:#F2F2F2;" | ED || QD 96tpi || SD
|-
! {{rh}} | Modulation 
| {{dunno}} || style="background:#F2F2F2;" | MFM || style="background:#F2F2F2;" | FM || style="background:#F2F2F2;" | MFM || style="background:#F2F2F2;" | MFM || FM || style="background:#F2F2F2;" | FM || style="background:#F2F2F2;" | MFM || style="background:#F2F2F2;" | MFM || MFM || MFM || style="background:#F2F2F2;" | MFM || style="background:#F2F2F2;" | MFM || MFM || MFM || MFM || MFM || style="background:#F2F2F2;" | MFM || style="background:#F2F2F2;" | MFM || MFM || FM
|-
! {{rh}} | Formatted capacity (KB) 
| {{dunno}} || style="background:#F2F2F2;" | 320 || style="background:#F2F2F2;" | 250 ("old")<!-- "256128 bytes free, old style" --><ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 1200 || style="background:#F2F2F2;" | 160 || 250 ("new")<!-- "255744 bytes free" --><ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 500 || style="background:#F2F2F2;" | 360 || style="background:#F2F2F2;" | 180 || 640 || 320 || style="background:#F2F2F2;" | 1200 || style="background:#F2F2F2;" | 720 || 1440 || 720 || 360 || 360 || style="background:#F2F2F2;" | 1440 || style="background:#F2F2F2;" | 2880 || 720 || 243&nbsp;/ 250
|-
! {{rh}} | Cylinders (CHS) 
| 77 || style="background:#F2F2F2;" | 40 || style="background:#F2F2F2;" | 77 || style="background:#F2F2F2;" | 77 || style="background:#F2F2F2;" | 40 || 77 || style="background:#F2F2F2;" | 77 || style="background:#F2F2F2;" | 40 || style="background:#F2F2F2;" | 40 || 80 || 80 || style="background:#F2F2F2;" | 80 || style="background:#F2F2F2;" | 80 || 80 || 80 || 80 || 80 || style="background:#F2F2F2;" | 80 || style="background:#F2F2F2;" | 80 || 80 || 77
|-
! {{rh}} | Physical sectors / track <br/>(BPB offset {{mono|[[#BPB331_OFS_0Dh|0x0D]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 8 || style="background:#F2F2F2;" | 26 || style="background:#F2F2F2;" | 8 || style="background:#F2F2F2;" | 8 || 26 || style="background:#F2F2F2;" | 26 || style="background:#F2F2F2;" | 9 || style="background:#F2F2F2;" | 9 || 8 || 8 || style="background:#F2F2F2;" | 15 || style="background:#F2F2F2;" | 9 || 18 || 9 (8<ref name="Lai_1992_DevDrv"/>) || 9 || 9 || style="background:#F2F2F2;" | 18 || style="background:#F2F2F2;" | 36 || 9 (8<ref name="Lai_1992_DevDrv"/>) || 26
|-
! {{rh}} | Number of heads <br/>(BPB offset {{mono|[[#BPB331_OFS_0Fh|0x0F]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 1<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 2<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/><ref name="Microsoft_2003_KB75131"/><ref name="Microsoft_2014_DEVDRIV"/> (1<!-- will have to find source for this again -->) || style="background:#F2F2F2;" | 1 || 1<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/><ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 2<ref name="Microsoft_2003_KB75131"/> || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 1 || 2 || 1 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 2 || 1 || 1 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 1
|-
! {{rh}} | Byte payload / physical sector 
| {{dunno}} || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 128 || style="background:#F2F2F2;" | 1024 || style="background:#F2F2F2;" | 512 || 128 || style="background:#F2F2F2;" | 128 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 512 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 512 || 512 || 512 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 128
|-
! {{rh}} | Bytes / logical sector <br/>(BPB offset {{mono|[[#BPB20_OFS_00h|0x00]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 128 || style="background:#F2F2F2;" | 1024 || style="background:#F2F2F2;" | 512 || 128 || style="background:#F2F2F2;" | 128 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 512 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 512 || 512 || 512 || style="background:#F2F2F2;" | 512 || style="background:#F2F2F2;" | 512 || 512 || 128
|-
! {{rh}} | Logical sectors / cluster <br/>(BPB offset {{mono|[[#BPB20_OFS_02h|0x02]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 4 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || 4 || style="background:#F2F2F2;" | 4 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 1 || 2 || 1<ref name="Microsoft_2003_KB75131"/> (2?<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>) || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 2 || 1 || {{dunno}} || 2 || {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 2 || {{dunno}} || 4
|-
! {{rh}} | Reserved logical sectors <br/>(BPB offset {{mono|[[#BPB20_OFS_03h|0x03]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || 4<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 4 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || 1 || 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 (2<!-- MS-DOS 6.22 DRIVER.SYS -->) || 1 || 1 || 1 || 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || {{dunno}} || 1
|-
! {{rh}} | Number of FATs <br/>(BPB offset {{mono|[[#BPB20_OFS_05h|0x05]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 2 || 2 || 2 || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 2
|-
! {{rh}} | Root directory entries <br/>(BPB offset {{mono|[[#BPB20_OFS_06h|0x06]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 112 (7 sectors) || style="background:#F2F2F2;" | 68 (17 sectors) || style="background:#F2F2F2;" | 192 (6 sectors) || style="background:#F2F2F2;" | 64 (4 sectors) || 68 (17 sectors) || style="background:#F2F2F2;" | 68 (17 sectors) || style="background:#F2F2F2;" | 112 (7 sectors) || style="background:#F2F2F2;" | 64 (4 sectors) || 112 (7 sectors) || 112 (7 sectors) || style="background:#F2F2F2;" | 224 (14 sectors) || style="background:#F2F2F2;" | 112 (7 sectors) || 224 (14 sectors) || {{dunno}} || 112 (7 sectors) || {{dunno}} || style="background:#F2F2F2;" | 224 (14 sectors) || style="background:#F2F2F2;" | 240 (15 sectors) || {{dunno}} || 64 (16 sectors)
|-
! {{rh}} | Total logical sectors <br/>(BPB offset {{mono|[[#BPB20_OFS_08h|0x08]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 640 || style="background:#F2F2F2;" | 2002<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 1232<ref name="Microsoft_2003_KB75131"/><ref name="Microsoft_2014_DEVDRIV"/> (616<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>) || style="background:#F2F2F2;" | 320 || 2002<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/><ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 4004<ref name="Microsoft_2003_KB75131"/> || style="background:#F2F2F2;" | 720 || style="background:#F2F2F2;" | 360 || 1280 || 640 || style="background:#F2F2F2;" | 2400 || style="background:#F2F2F2;" | 1440 || 2880 || {{dunno}} || 720 || {{dunno}} || style="background:#F2F2F2;" | 2880 || style="background:#F2F2F2;" | 5760 || {{dunno}} || 2002
|-
! {{rh}} | Logical sectors / FAT <br/>(BPB offset {{mono|[[#BPB20_OFS_0Bh|0x0B]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 6<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 1 || 6<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/> || style="background:#F2F2F2;" | 6?<ref name="Microsoft_2003_KB75131"/><!-- 4 (2)--> || style="background:#F2F2F2;" | 2 || style="background:#F2F2F2;" | 2 || 2 || 2<ref name="Microsoft_2003_KB75131"/> (1?<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>) || style="background:#F2F2F2;" | 7 || style="background:#F2F2F2;" | 3 || 9 (7) || {{dunno}} || 2 || {{dunno}} || style="background:#F2F2F2;" | 9 || style="background:#F2F2F2;" | 9 || {{dunno}} || 1
|-
! {{rh}} | Hidden sectors <br/>(BPB offset {{mono|[[#BPB331_OFS_11h|0x11]]}}) 
| {{dunno}} || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 3<ref name="Microsoft_2003_KB75131"/> (0<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>) || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || 0 || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || 0 || 0 || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || 0 || 0 || 0 || 0 || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || {{dunno}} || 0
|-
! {{rh}} | Total number of clusters 
| {{dunno}} || style="background:#F2F2F2;" | 315 || style="background:#F2F2F2;" | 497 || style="background:#F2F2F2;" | 1227 || style="background:#F2F2F2;" | 313 || {{dunno}} || style="background:#F2F2F2;" | 997?<ref name="Microsoft_2003_KB75131"/> || style="background:#F2F2F2;" | 354 || style="background:#F2F2F2;" | 351 || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | 2371 || style="background:#F2F2F2;" | 713 || 2847? || {{dunno}} || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | 2847 || style="background:#F2F2F2;" | 2863 || {{dunno}} || {{dunno}}
|-
! {{rh}} | Logical sector order 
| {{dunno}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}} || {{dunno}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}} || {{dunno}} || {{dunno}} || {{dunno}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}} || {{dunno}}
|-
! {{rh}} | Sector mapping 
| {{dunno}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|sector+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|sector+ head+ track+}} || {{verth|sector+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|sector+ head+ track+}} || {{dunno}} || {{verth|sector+ track+}} || {{verth|sector+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{verth|cellstyle=background:#F2F2F2;|sector+ head+ track+}} || {{dunno}} || {{verth|sector+ track+}}
|-
! {{rh}} | First physical sector (CHS) 
| {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || 1 || {{dunno}} || 1 || {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 1 || {{dunno}} || 1
|-
! {{rh}} | {{code|DRIVER.SYS /F:n}}
| {{dunno}} || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 3 || style="background:#F2F2F2;" | 4 || style="background:#F2F2F2;" | 0 || {{dunno}} || style="background:#F2F2F2;" | 3 || style="background:#F2F2F2;" | 0 || style="background:#F2F2F2;" | 0 || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | 1 || style="background:#F2F2F2;" | 2 || 7 || {{dunno}} || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | 7 || style="background:#F2F2F2;" | 9 || {{dunno}} || 3
|-
! {{rh}} | BPB Presence 
| {{dunno}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}}  || {{dunno|style="background:#F2F2F2;" }} || {{dunno|style=background:#F2F2F2;}} || {{dunno|style=background:#F2F2F2;}} || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | Yes || style="background:#F2F2F2;" | Yes || Yes || {{dunno}} || {{dunno}} || {{dunno}} || style="background:#F2F2F2;" | Yes || style="background:#F2F2F2;" | Yes || {{dunno}} || {{dunno}}
|-
! {{rh}} | Support 
| {{dunno}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 1.1<ref name="Microsoft_2014_DEVDRIV"/>}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 1.0<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/>}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 2.0}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 1.0<ref name="Microsoft_2014_DEVDRIV"/>}} 
| {{dunno}}<ref name="Microsoft_2014_Altos"/><ref name="Microsoft_2014_DEVDRIV"/><!-- "255744 bytes free" --> 
| {{verth|cellstyle=background:#F2F2F2;|DOS 2.0}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 2.0}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 2.0}} 
| {{dunno}} || {{dunno}} || {{verth|cellstyle=background:#F2F2F2;|DOS 3.0}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 3.2}} 
| {{verth|DOS 3.2 only;<br/>(DR-DOS<!-- at least 7.0-7.03 -->)}} 
| {{verth|Sanyo 55x<br/>DS-DOS 2.11 only}} 
| {{verth|MS-DOS 3.1<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>}} 
| {{verth|MSX-DOS}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 3.3}} 
| {{verth|cellstyle=background:#F2F2F2;|DOS 5.0}} 
| {{verth|Tandy 2000 only}} 
| {{verth|DR-DOS only<!-- at least 3.41-8.1, possibly earlier, but not 3.31 -->}}
|}</div>
Microsoft recommends to distinguish between the two 8-inch formats for FAT ID {{mono|0xFE}} by trying to read of a single-density address mark. If this results in an error, the medium must be double-density.<ref name="Microsoft_1987_DOS33Ref"/>

The table does not list a number of incompatible 8-inch and 5.25-inch [[86-DOS disk formats|FAT12 floppy formats supported by 86-DOS]], which differ either in the size of the directory entries (16 bytes vs. 32 bytes) or in the extent of the reserved sectors area (several whole tracks vs. one logical sector only).

The implementation of a single-sided 315 KB FAT12 format used in [[MS-DOS]] for the [[Apricot PC]] and [[Apricot F1e|F1e]]<ref name="USERPROMPT_1985_PORTDOS"/> 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 (offsets {{mono|[[#BPB20_OFS_00h|0x00B]]}}-{{mono|[[#BPB20_OFS_0Bh|0x017]]}} in the standard boot sector) were located at offset {{mono|0x050}}. The [[Apricot Portable|Portable]], [[Apricot F1|F1]], [[Apricot PC duo|PC duo]] and [[Apricot Xi FD|Xi FD]] supported a non-standard double-sided 720 KB FAT12 format instead.<ref name="USERPROMPT_1985_PORTDOS"/> 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: {{mono|0xFC}}, logical sectors per FAT: 2, physical sectors per track: 9, number of heads: 1.<ref name="USERPROMPT_1985_PORTDOS"/><ref name="Elliott_1998_DOSPLUS2"/>
* 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: {{mono|0xFE}}, logical sectors per FAT: 3, physical sectors per track: 9, number of heads: 2.<ref name="USERPROMPT_1985_PORTDOS"/>
Later versions of [[Apricot MS-DOS]] gained the ability to read and write disks with the standard boot sector in addition to those with the Apricot one. These formats were also supported by [[DOS Plus]] 2.1e/g for the Apricot ACT series.

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.<ref name="Elliott_1998_DOSPLUS2"/> 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 [[Advanced Disc Filing System|ADFS]] file system containing the boot loader, followed by a single FAT.<ref name="Elliott_1998_DOSPLUS2"/><ref name="YELPIG_BBCMASTER"/> Also, the 640 KB format differed by using physical CHS sector numbers starting with 0 (not 1, as common) and incrementing sectors in the order sector-track-head (not sector-head-track, as common).<ref name="YELPIG_BBCMASTER"/> 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<!-- Elliott writes 176, which is wrong -->, total logical sectors: 800, FAT ID: {{mono|0xFD}}, logical sectors per FAT: 2, physical sectors per track: 5, number of heads: 2.<ref name="Elliott_1998_DOSPLUS2"/><ref name="YELPIG_BBCMASTER"/>
* 640 KB: Bytes per logical sector: 256 bytes, logical sectors per cluster: 8, reserved logical sectors: 16<!-- YellowPig writes 9, which is wrong -->, number of FATs: 1, root directory entries: 112, total logical sectors: 2560, FAT ID: {{mono|0xFF}}, logical sectors per FAT: 2, physical sectors per track: 16, number of heads: 2.<ref name="Elliott_1998_DOSPLUS2"/><ref name="YELPIG_BBCMASTER"/>
DOS Plus for the Master 512 could also access standard PC disks formatted to {{nowrap|180 KB}} or {{nowrap|360 KB}}, using the first byte of the FAT in logical sector 1 to determine the capacity.<!-- and ignoring the root dir entries field in the BPB, which it erroneously wrote as 8 instead of the correct 7. -->

The DEC Rainbow 100 (all variations) 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 (MS-DOS used a static in-memory BPB instead). The boot sector (track 0, side 0, sector 1) was Z80 code beginning with DI {{mono|0xF3}}. The 8088 bootstrap was loaded by the Z80. Track 1, side 0, sector 2 starts with the Media/FAT ID byte {{mono|0xFA}}. Unformatted disks use {{mono|0xE5}} 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.<ref>Digital Equipment Corporation. Rainbow 100 MS-DOS 2.01 Technical Documentation Volume 1 (QV025-GZ), Microsoft MS-DOS Operating System BIOS Listing (AA-X432A-TV), Universal Disk Driver, Page 1-17. 1983.</ref>

=== FS Information Sector ===<!-- NB. The header "FS Information Sector" is used in local links in this page. -->

The "FS Information Sector" was introduced in FAT32<ref name="DEW_FAT-Bootsector"/> for speeding up access times of certain operations (in particular, getting the amount of free space). It is located at a logical sector number specified in the FAT32 EBPB boot record at position {{mono|[[#EBPB32_OFS_25h|0x030]]}} (usually logical sector 1, immediately after the boot record itself).

{| class="wikitable sortable mw-collapsible"
|-
! Byte offset
! Length (bytes)
! Contents
|-
| style="text-align:right;"| 0x000
| style="text-align:right;"| 4
| FS information sector signature ({{mono|0x52 0x52 0x61 0x41}} = "<code>[[Aaron R. Reynolds|RRaA]]</code>")

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 (with only one reserved sectors), 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 [[#CLUST_0|cluster 0]] and [[#CLUST_1|cluster 1]] to follow certain bit patterns, which are not met by this signature.
|-
| style="text-align:right;"| 0x004
| style="text-align:right;"| 480
| Reserved (byte values should be set to {{mono|0x00}} during format, but not be relied upon and never changed later on)
|-
| style="text-align:right;"| 0x1E4
| style="text-align:right;"| 4
| FS information sector signature ({{mono|0x72 0x72 0x41 0x61}} = "<code>[[Aaron R. Reynolds|rrAa]]</code>")
|-
| style="text-align:right;"| 0x1E8
| style="text-align:right;"| 4
| Last known number of free data clusters on the volume, or {{mono|0xFFFFFFFF}} if unknown. Should be set to {{mono|0xFFFFFFFF}} 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.
|-
| style="text-align:right;"| 0x1EC
| style="text-align:right;"| 4
| Number of the most recently known to be allocated data cluster. Should be set to {{mono|0xFFFFFFFF}} during format and updated by the operating system later on. With {{mono|0xFFFFFFFF}} the system should start at cluster {{mono|0x00000002}}. 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.
|-
| style="text-align:right;"| 0x1F0
| style="text-align:right;"| 12
| Reserved (byte values should be set to {{mono|0x00}} during format, but not be relied upon and never changed later on)
|-
| style="text-align:right;"| 0x1FC
| style="text-align:right;"| 4
| FS information sector signature ({{mono|0x00 0x00 0x55 0xAA}})<ref name="efi"/><ref group="nb" name="NB_Magic_AA55"/> (All four bytes should match before the contents of this sector should be assumed to be in valid format.)<!-- because boot sectors use the same signature, but explicitly only use 0x55 0xAA at offset 0x1FE, not 0x00 0x00 at 0x1FC. -->
|}

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 [[#CLUST_1|cluster 1]] or the FAT32 EBPB at offset {{mono|[[#EBPB32_OFS_36h|0x041]]}} 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|fragmentation]].

If this sector is present on a FAT32 volume, the minimum allowed [[#BPB20_OFS_00h|logical sector size]] is 512&nbsp;bytes, whereas otherwise it would be 128&nbsp;bytes. Some FAT32 implementations support a slight variation of Microsoft's specification by making the FS information sector optional by specifying a value of {{mono|0xFFFF}}<ref name="Brown_2002_INTER61"/> (or {{mono|0x0000}}) in the entry at offset {{mono|[[#EBPB32_OFS_25h|0x030]]}}.<!-- but it is not clear how MS operating systems behave then, in the worst case, they could trash the volume -->

== FAT region ==

=== File Allocation Table ===
<span id="FAT"></span><!-- NB. The header "File Allocation Table" is used in local links in this page. -->

==== Cluster map ====
{{overcolored}}
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 {{nowrap|32 [[Kibibyte|KiB]]}}.<ref>{{Cite book|last=Tyagi|first=Tarun|url=https://www.datadoctor.biz/data_recovery_programming_book_chapter3-page4.html|title=Data Recovery With and Without Programming|date=2004-10-31|publisher=Gardners Books|isbn=978-81-7656-922-4|location=New Delhi, India|pages=4|chapter=Clusters size in FAT and NTFS file systems|access-date=2021-12-03 |archive-date=2021-12-03 |archive-url=https://web.archive.org/web/20211203034356/https://www.datadoctor.biz/data_recovery_programming_book_chapter3-page4.html|url-status=live}}</ref>

Each file may occupy one or more clusters depending on its size. Thus, a file is represented by a chain of clusters (referred to as a [[singly linked list]]). These clusters are not necessarily stored 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.

{{anchor|FAT12}}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 (e.g. cluster 0) and the 12 most significant bits the second (e.g. cluster 1). 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.

{| class="wikitable"
|+ Example of FAT12 table start with several cluster chains
|-
! Offset
! +0 !! +1 !! +2 !! +3 !! +4 !! +5 !! +6 !! +7 !! +8 !! +9 !! +A !! +B !! +C !! +D !! +E !! +F
|-
! +0000
|style="background:darksilver;"|[[#CLUST 0|F0]]
||<span style="background:silver;">[[#CLUST 1|F]]</span><span style="background:darksilver;">[[#CLUST 0|F]]</span>
|style="background:silver;"|[[#CLUST 1|FF]]
|style="background:cyan;"|03
|style="background:cyan;"|40
|style="background:cyan;"|00
|style="background:cyan;"|05
|style="background:cyan;"|60
|style="background:cyan;"|00
|style="background:cyan;"|07
|style="background:cyan;"|80
|style="background:cyan;"|00
|style="background:cyan;"|[[#FAT EOC|FF]]
||<span style="background:yellow;">A</span><span style="background:cyan;">[[#FAT EOC|F]]</span>
|style="background:yellow;"|00
|style="background:yellow;"|14
|-
! +0010
||<span style="background:orange;">C</span><span style="background:yellow;">0</span>
|style="background:orange;"|00
|style="background:orange;"|0D
|style="background:orange;"|E0
|style="background:orange;"|00
|style="background:orange;"|0F
|style="background:orange;"|00
|style="background:orange;"|01
|style="background:orange;"|11
|style="background:orange;"|[[#FAT EOC|F]]0
|style="background:orange;"|[[#FAT EOC|FF]]
||00
||<span style="background:lightgreen;">[[#Directory table|F]]</span>0
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:yellow;"|15
|style="background:yellow;"|60
|-
! +0020
|style="background:yellow;"|01
|style="background:yellow;"|19
||<span style="background:pink;">[[#BAD CLUST|7]]</span><span style="background:yellow;">0</span>
|style="background:pink;"|[[#BAD CLUST|FF]]
|style="background:pink;"|[[#BAD CLUST|F7]]
||<span style="background:yellow;">A</span><span style="background:pink;">[[#BAD CLUST|F]]</span>
|style="background:yellow;"|01
|style="background:yellow;"|[[#FAT EOC|FF]]
||0<span style="background:yellow;">[[#FAT EOC|F]]</span>
||00
||00
||<span style="background:pink;">[[#BAD CLUST|7]]</span>0
|style="background:pink;"|[[#BAD CLUST|FF]]
||00
||00
||00
|}
{{smalldiv|
* {{background color|darksilver|[[#FATID|FAT ID]] / endianness marker (in reserved cluster [[#CLUST 0|#0]]), with [[#BPB20 OFS 0Ah|0xF0]]<!-- should point to FAT ID rather than media ID, but media ID table is more meaningful here --> indicating a volume on a non-partitioned [[superfloppy]] drive (must be [[#BPB20 OFS 0Ah|0xF8]] for partitioned disks)}}
* {{background color|silver|End of chain indicator / maintenance flags (in reserved cluster [[#CLUST 1|#1]])}}
* {{background color|cyan|Second chain (7 clusters) for a non-fragmented file (here: #2, #3, #4, #5, #6, #7, #8)}}
* {{background color|yellow|Third chain (7 clusters) for a fragmented, possibly grown file (here: #9, #A, #14, #15, #16, #19, #1A)}}
* {{background color|orange|Fourth chain (7 clusters) for a non-fragmented, possibly truncated file (here: #B, #C, #D, #E, #F, #10, #11)}}
* Empty clusters (here: #12, #1B, #1C, #1E, #1F)
* {{background color|lightgreen|Fifth chain (1 cluster) for a sub-directory (here: #13)}}
* {{background color|pink|Bad clusters (3 clusters) (here: #17, #18, #1D)}}
}}

{{anchor|FAT16}}The [[FAT16]] file system uses 16 bits per FAT entry, thus one entry spans two bytes in little-endian byte order:

{| class="wikitable"
|+ Example of FAT16 table start with several cluster chains
|-
!Offset
!+0!!+1!!+2!!+3!!+4!!+5!!+6!!+7!!+8!!+9!!+A!!+B!!+C!!+D!!+E!!+F
|-
!+0000
|style="background:darksilver;"|[[#CLUST_0|F0]]
|style="background:darksilver;"|[[#CLUST_0|FF]]
|style="background:silver;"|[[#CLUST_1|FF]]
|style="background:silver;"|[[#CLUST_1|FF]]
|style="background:cyan;"|03
|style="background:cyan;"|00
|style="background:cyan;"|04
|style="background:cyan;"|00
|style="background:cyan;"|05
|style="background:cyan;"|00
|style="background:cyan;"|06
|style="background:cyan;"|00
|style="background:cyan;"|07
|style="background:cyan;"|00
|style="background:cyan;"|08
|style="background:cyan;"|00
|-
!+0010
|style="background:cyan;"|[[#FAT_EOC|FF]]
|style="background:cyan;"|[[#FAT_EOC|FF]]
|style="background:yellow;"|0A
|style="background:yellow;"|00
|style="background:yellow;"|14
|style="background:yellow;"|00
|style="background:orange;"|0C
|style="background:orange;"|00
|style="background:orange;"|0D
|style="background:orange;"|00
|style="background:orange;"|0E
|style="background:orange;"|00
|style="background:orange;"|0F
|style="background:orange;"|00
|style="background:orange;"|10
|style="background:orange;"|00
|-
!+0020
|style="background:orange;"|11
|style="background:orange;"|00
|style="background:orange;"|[[#FAT_EOC|FF]]
|style="background:orange;"|[[#FAT_EOC|FF]]
||00
||00
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:yellow;"|15
|style="background:yellow;"|00
|style="background:yellow;"|16
|style="background:yellow;"|00
|style="background:yellow;"|19
|style="background:yellow;"|00
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|-
!+0030
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:yellow;"|1A
|style="background:yellow;"|00
|style="background:yellow;"|[[#FAT_EOC|FF]]
|style="background:yellow;"|[[#FAT_EOC|FF]]
||00
||00
||00
||00
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
||00
||00
||00
||00
|}

{{anchor|FAT32}}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.

{| class="wikitable"
|+ Example of FAT32 table start with several cluster chains
|-
!Offset
! +0 !! +1 !! +2 !! +3 !! +4 !! +5 !! +6 !! +7 !! +8 !! +9 !! +A !! +B !! +C !! +D !! +E !! +F
|-
! +0000
|style="background:darksilver;"|[[#CLUST_0|F0]]
|style="background:darksilver;"|[[#CLUST_0|FF]]
|style="background:darksilver;"|[[#CLUST_0|FF]]
|style="background:darksilver;"|[[#CLUST_0|0F]]
|style="background:silver;"|[[#CLUST_1|FF]]
|style="background:silver;"|[[#CLUST_1|FF]]
|style="background:silver;"|[[#CLUST_1|FF]]
|style="background:silver;"|[[#CLUST_1|0F]]
|style="background:lightblue;"|[[#Directory table|FF]]
|style="background:lightblue;"|[[#Directory table|FF]]
|style="background:lightblue;"|[[#Directory table|FF]]
|style="background:lightblue;"|[[#Directory table|0F]]
|style="background:cyan;"|04
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|00
|-
! +0010
|style="background:cyan;"|05
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|06
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|07
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|08
|style="background:cyan;"|00
|style="background:cyan;"|00
|style="background:cyan;"|00
|-
! +0020
|style="background:cyan;"|[[#FAT_EOC|FF]]
|style="background:cyan;"|[[#FAT_EOC|FF]]
|style="background:cyan;"|[[#FAT_EOC|FF]]
|style="background:cyan;"|[[#FAT_EOC|0F]]
|style="background:yellow;"|0A
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|14
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:orange;"|0C
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|-
! +0030
|style="background:orange;"|0D
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|0E
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|0F
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|10
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|-
! +0040
|style="background:orange;"|11
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|00
|style="background:orange;"|[[#FAT_EOC|FF]]
|style="background:orange;"|[[#FAT_EOC|FF]]
|style="background:orange;"|[[#FAT_EOC|FF]]
|style="background:orange;"|[[#FAT_EOC|0F]]
||00
||00
||00
||00
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:lightgreen;"|[[#Directory table|FF]]
|style="background:lightgreen;"|[[#Directory table|0F]]
|-
! +0050
|style="background:yellow;"|15
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|16
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|19
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|0F]]
|-
! +0060
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|0F]]
|style="background:yellow;"|1A
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|00
|style="background:yellow;"|[[#FAT_EOC|FF]]
|style="background:yellow;"|[[#FAT_EOC|FF]]
|style="background:yellow;"|[[#FAT_EOC|FF]]
|style="background:yellow;"|[[#FAT_EOC|0F]]
||00
||00
||00
||00
|-
! +0070
||00
||00
||00
||00
|style="background:pink;"|[[#BAD_CLUST|F7]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|FF]]
|style="background:pink;"|[[#BAD_CLUST|0F]]
||00
||00
||00
||00
||00
||00
||00
||00
|}
{{smalldiv|
* {{background color|lightblue|First chain (1 cluster) for the root directory, pointed to by an entry in the [[#EBPB32 OFS 21h|FAT32 BPB]] (here: #2)}}
* {{background color|cyan|Second chain (6 clusters) for a non-fragmented file (here: #3, #4, #5, #6, #7, #8)}}
}}

The ''File Allocation Table'' (''FAT'') 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 five things:
* the cluster number of the next cluster in a chain
* a special ''end of cluster-chain'' (''EOC'') 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

For very early versions of DOS to recognize the file system, the system must have been booted from the volume<!-- so that the OS is adapted to cope with any peculiarities of the medium --> or the volume's FAT must start with the volume's second sector (logical sector 1 with physical CHS address 0/0/2 or LBA address 1), that is, immediately following the boot sector. Operating systems assume this hard-wired location of the FAT in order to find the [[#FATID|FAT ID]] in the FAT's cluster 0 entry on DOS 1.0-1.1 FAT diskettes, where no valid BPB is found.

==== Special entries ====

The first two entries in a FAT store special values:

{{anchor|CLUST_0}}The first entry (cluster 0 in the FAT) holds the FAT ID since [[MS-DOS 1.20]] and [[PC DOS 1.1]] (allowed values {{mono|0xF0}}-{{mono|0xFF}} with {{mono|0xF1}}-{{mono|0xF7}} reserved) in bits 7-0, which is also copied into the BPB of the boot sector, offset {{mono|[[#BPB20_OFS_0Ah|0x015]]}} since DOS 2.0. The remaining 4 bits (if FAT12), 8 bits (if FAT16) or 20 bits (if FAT32) of this entry are always 1.<!-- TBD. May not be present on early Atari GEMDOS volumes. --><!-- ON FAT12/FAT16 volumes, DR-DOS depends on these remaining bits to be 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.<!-- It is not known, if this was merely for cosmetics only, or if MS-DOS actually depends on this. --> Additionally, for FAT IDs other than {{mono|0xFF}} (and {{mono|0x00}}) it is possible to determine the correct nibble and byte order (to be) 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.<!-- nevertheless, byte orders could erroneously get swapped in network transfers of file system images, so it's still good to have a way to check it --> [[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.<!-- exact magic values TBD -->

{{anchor|CLUST_1}}The second entry (cluster 1 in the FAT) nominally stores the end-of-cluster-chain marker as used by the formater, but typically always holds {{mono|0xFFF}} / {{mono|0xFFFF}} / {{mono|0x0FFFFFFF}}<!-- TBD. May not be set up properly on early Atari GEMDOS volumes -->, that is, with the exception of bits 31-28 on FAT32 volumes these bits are normally always set. Some Microsoft operating systems<!-- Windows 95 OSR2 / 98 / 98 SE / ME, Windows 2000, Windows XP -->, however, set these bits if the volume is not the volume holding the running operating system (that is, use {{mono|0xFFFFFFFF}} instead of {{mono|0x0FFFFFFF}} here).<ref name="Sedory_2001_DirtyFlags"/> (In conjunction with alternative end-of-chain markers the lowest bits 2-0 can become zero for the lowest allowed end-of-chain marker {{mono|0xFF8}} / {{mono|0xFFF8}} / {{mono|0x?FFFFFF8}}; bit 3 should be reserved as well given that clusters {{mono|0xFF0}} / {{mono|0xFFF0}} / {{mono|0x?FFFFFF0}} and higher are officially reserved.<!-- and its correspondence with the FAT ID and media descriptor value --> Some operating systems may not be able to mount some volumes if any of these bits are not set, therefore the default end-of-chain marker should not be changed.<!-- DR-DOS tests for both bytes at offset +1 and +2 in the FAT to be FFh before using the FAT ID at offset +0, but only when no valid BPB was found. -->) For DOS 1 and 2, the entry was documented as reserved for future use.

Since DOS 7.1<!-- recheck introduction. Windows 95 OSR2? --> 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.<!-- NB. The reason, why this is not supported on FAT12, is down to many older operating system depending on the bytes at offset +1 and +2 in the first FAT to be all set in order to recognize the volume. See above. --> 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:<br/>
If bit 15 (on FAT16) or bit 27 (on FAT32)<ref name="Microsoft_1998_CC768180"/> 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.<ref name="AB" /> On FAT32 volumes, the [[#FS Information Sector|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<ref group="nb" name="NB_WIN98_WINCOM"/><ref name="Microsoft_1998_CC768180"/> (but not on insertion of removable media<!-- might be important in conjunction with TFAT, details to be sorted out -->) to ensure and possibly reestablish the volume's integrity.<br/>
If bit 14 (on FAT16) or bit 26 (on FAT32)<ref name="Microsoft_1998_CC768180"/> is cleared, the operating system has encountered disk I/O errors on startup,<ref name="Microsoft_1998_CC768180"/> a possible indication for bad sectors. Operating systems aware of this extension will interpret this as a recommendation to carry out a surface scan ([[SCANDISK]]) on the next boot.<ref name="AB" /><ref name="Microsoft_1998_CC768180"/> (A similar set of bitflags exists in the FAT12/FAT16 EBPB at offset {{mono|[[#EBPB_OFS_1Ah|0x1A]]}} or the FAT32 EBPB at offset {{mono|[[#EBPB32_OFS_36h|0x36]]}}. While the cluster 1 entry can be accessed by file system drivers once they have mounted the volume, the EBPB entry is available even when the volume is not mounted and thus easier to use by disk block device drivers or partitioning tools.)

If the number of FATs in the BPB is not set to 2<!-- that is, typically 1, but TFAT presumably actually tests for "not 2" -->, the second cluster entry in the first FAT (cluster 1) 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,<!-- really all bits cleared, not just one special bit? --> 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.<!-- really all bits set, not just one special bit? --><!-- more details TBD -->

Some non-standard FAT12/FAT16 implementations utilize the cluster 1 entry to store the starting cluster of a variable-sized root directory (typically 2<ref name="two"/>). This may occur when the [[#BPB20_OFS_06h|number of root directory entries]] in the BPB holds a value of 0 and no FAT32 EBPB is found (no signature {{mono|0x29}} or {{mono|0x28}} at offset {{mono|[[#EBPB32_OFS_37h|0x042]]}}).<ref name="BoynePollard_2010_BPB"/> This extension, however, is not supported by mainstream operating systems,<ref name="BoynePollard_2010_BPB"/> 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 values >=2 and -->for FAT12 with less than {{mono|0xFEF}}<!-- to avoid problems with usage of bits 3-0 --> and FAT16 volumes with less than {{mono|0x3FEF}}<!-- to avoid problems with maintenance flags in bits 15&14 --> clusters and 2 FATs.<!-- because TFAT never indicates 2 FATs -->

Because these first two FAT entries store special values, there are no data clusters 0 or 1. The first data cluster (after the root directory if FAT12/FAT16) is cluster 2,<ref name="two" /> marking the beginning of the data area.

==== Cluster values ====

FAT entry values:

{| class="wikitable"
|-
! FAT12
! FAT16
! FAT32
! Description
|-
| 0x000
| 0x0000
| {{nowrap|0x?0000000}}
| 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.<ref name="Schulman_1994_Undocumented-DOS"/><ref name="Chappell_1994_DOS-Internals"/>
Otherwise, if this value occurs in cluster chains (e.g. in directory entries of zero length or deleted files), file system implementations should treat this like an end-of-chain marker.<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>
|-
| 0x001
| 0x0001
| {{nowrap|0x?0000001}}
| Reserved for internal purposes; MS-DOS/PC&nbsp;DOS use this cluster value as a temporary non-free cluster indicator while constructing cluster chains during file allocation (only seen on disk if there is a crash or power failure in the middle of this process).<ref name="Schulman_1994_Undocumented-DOS"/><ref name="Chappell_1994_DOS-Internals"/>
If this value occurs in on-disk cluster chains, file system implementations should treat this like an end-of-chain marker.
|-
| 0x002&nbsp;- 0xFEF
| 0x0002&nbsp;- 0xFFEF (0x0002&nbsp;- 0x7FFF)
| {{nowrap|0x?0000002 -}} {{nowrap|0x?FFFFFEF}}
| Used as data clusters; value points to next cluster. MS-DOS/PC&nbsp;DOS accept values up to {{mono|0xFEF}} / {{mono|0xFFEF}} / {{mono|0x0FFFFFEF}} (sometimes more; see below), whereas for Atari GEMDOS only values up to {{mono|0x7FFF}} are allowed on FAT16 volumes.
|-
| 0xFF0<ref group="nb" name="NB_MAGIC_FF0"/>&nbsp;- 0xFF5 (0xFF1&nbsp;- 0xFF5)
| 0xFFF0&nbsp;- 0xFFF5
| {{nowrap|0x?FFFFFF0 -}} {{nowrap|0x?FFFFFF5}}
| Reserved in some contexts,<ref name="Norton2" /> or also used<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/><ref name="efi"/><ref name="max4084"/> 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 (ideally applying additional sanity checks), similar to what MS-DOS, PC DOS and DR-DOS do,<ref name="Chappell_1994_DOS-Internals"/> and should avoid allocating them for files otherwise.<!-- One German Microsoft press book by Günter Born "MS-DOS 6.22 Programmierhandbuch" claims they should be treated as additional "bad cluster" markers, but I think this is misleading. -->

MS-DOS/PC&nbsp;DOS 3.3 and higher<!-- at least up to 6.x. possibly higher --> treats a value of {{mono|0xFF0}}<ref group="nb" name="NB_MAGIC_FF0"/><ref name="Chappell_1994_DOS-Internals"/> on FAT12 (but not on FAT16 or FAT32) volumes as additional end-of-chain marker similar to {{mono|0xFF8}}-{{mono|0xFFF}}.<ref name="Chappell_1994_DOS-Internals"/> For compatibility with MS-DOS/PC&nbsp;DOS, file systems should avoid to use data cluster {{mono|0xFF0}} in cluster chains on FAT12 volumes (that is, treat it as a reserved cluster similar to {{mono|0xFF7}}). (NB. The correspondence of the low byte of the cluster number with the FAT ID and media descriptor values is the reason, why these cluster values are reserved.)
|-
| 0xFF6
| 0xFFF6
| {{nowrap|0x?FFFFFF6}}
| Reserved; do not use.<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/><ref name="efi" /><ref name="msdosref" /><ref name="max4084" /> (NB. Corresponds with the default format filler value {{mono|0xF6}} on IBM compatible machines.) 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 (ideally applying additional sanity checks), and should avoid to allocate it for files otherwise.<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>
|-
| {{anchor|BAD_CLUST}}0xFF7
| 0xFFF7
| {{nowrap|0x?FFFFFF7}}
| Bad sector in cluster or reserved cluster (since DOS 2.0).

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 ({{mono|0xFF5}} and {{mono|0xFFF5}},<ref name="Chappell_1994_DOS-Internals"/> respectively) will always be smaller than this value.<ref name="Chappell_1994_DOS-Internals"/> Therefore, this value cannot normally occur in cluster-chains, but if it does, it may be treated as a normal data cluster, since {{mono|0xFF7}} 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,<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> and {{mono|0xFFF7}} could have been a non-standard data cluster on FAT16 volumes before the introduction of FAT32 with DOS 7.10. Theoretically, {{mono|0x0FFFFFF7}} 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 to allocate this cluster for files.<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/>

Disk utilities must not attempt to restore "lost clusters" holding this value in the FAT, but count them as bad clusters.
|-
| {{anchor|FAT_EOC}}0xFF8&nbsp;- 0xFFF (and optionally 0xFF0;<ref group="nb" name="NB_MAGIC_FF0"/> see note)
| 0xFFF8&nbsp;- 0xFFFF
| {{nowrap|0x?FFFFFF8 -}} {{nowrap|0x?FFFFFFF}}
| Last cluster in file (EOC). File system implementations must treat all these values as end-of-chain marker at the same time.<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> Most file system implementations (including 86-DOS, MS-DOS, PC DOS and DR-DOS) use {{mono|0xFFF}}<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> / {{mono|0xFFFF}}<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> / {{mono|0x0FFFFFFF}} as end-of-file marker when allocating files, but versions of Linux before 2.5.40 used {{mono|0xFF8}} / {{mono|0xFFF8}} / {{mono|0x0FFFFFF8}}.<ref name="Brouwer_2002_FAT"/> Versions of mkdosfs ([[dosfstools]] up to 3.0.26) continue to use {{mono|0x0FFFFFF8}} for the root directory on FAT32 volumes<!-- due to a bug -->, whereas some disk repair and defragment tools utilize other values in the set (e.g., SCANDISK may use {{mono|0xFF8}} / {{mono|0xFFF8}} / {{mono|0x0FFFFFF8}} instead). While in the original [[8-bit FAT]] implementation in Microsoft's [[Standalone Disk BASIC]] different end markers ({{mono|0xC0}}..{{mono|0xCD}}) were used to indicate the number of sectors (0 to 13) used up in the last cluster occupied by a file<!-- according to Marc McDonald in 2012: http://en.wikipedia.org/w/index.php?title=User_talk%3AMarcMcd&diff=507492609&oldid=504452782 -->, different end markers were repurposed under DOS to indicate different types of media,<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> with the currently used end marker indicated in the [[#CLUST_1|cluster 1]] entry, however, this concept does not seem to have been broadly utilized in practice&mdash;and to the extent that in some scenarios volumes may not be recognized by some operating systems, if some of the low-order bits<!-- at least bits 3-0 --> of the value stored in cluster 1 are not set. Also, some faulty file system implementations only accept {{mono|0xFFF}} / {{mono|0xFFFF}} / {{mono|0x?FFFFFFF}} 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.
(The low byte of the cluster number conceptually corresponds with the [[#FATID|FAT ID]] and [[#media|media descriptor]] values;<ref name="Microsoft_1984_MS-DOS_3.1_Ref"/> see note above for MS-DOS/PC&nbsp;DOS special usage of {{mono|0xFF0}}<ref group="nb" name="NB_MAGIC_FF0"/> on FAT12 volumes.<ref name="Chappell_1994_DOS-Internals"/><!-- TBD. Did some old 86-DOS implementations perhaps default to the media descriptor byte as EOC value? It could also have been used to indicate different file types. -->)
|}
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.<!-- (Besides the standard FAT32 file system as described above OEM DR-DOS 7.07 also defines a bootable special purpose "big" variant named "FAT32B  " in the EBPB, where all 32 bits are actually used for the cluster number.) -->

== 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 ===<!-- NB. The header "Directory table" is used in local links in this page. -->

A ''directory table'' is a special type of file that represents a [[directory (computing)|directory]] (also known as a folder). Since [[86-DOS 0.42]],<ref name="SCP_1981_86-DOS_1.0_Addendum"/><!-- and according to Marc McDonald in 2012-08 --> each file or (since MS-DOS 1.40 and PC&nbsp;DOS 2.0) subdirectory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes ([[archive bit|archive]], directory, hidden, read-only, system and volume<!-- not all attributes supported by very old versions -->), the address of the first cluster of the file/directory's data, the size of the file/directory, and the date<ref name="SCP_1981_86-DOS_1.0_Addendum"/> and (since PC&nbsp;DOS 1.1) 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.<ref name="SCP_1981_86-DOS_1.0_Addendum"/>

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 (CDS) under MS-DOS/PC&nbsp;DOS limits the absolute path of a directory to 66 characters (including the drive letter, but excluding the NUL byte delimiter),<ref name="Ecma-107"/><ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/><!-- ECMA-107 defines the limit without the preceding "<code>A:\</code>", therefore their 63 characters equals our 66 characters --> thereby limiting the maximum supported depth of subdirectories to 32<!-- "A:\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2\3\4\5\6\7\8\9\0\1\2" -->, whatever occurs earlier. Concurrent DOS, Multiuser&nbsp;DOS and DR&nbsp;DOS&nbsp;3.31 to 6.0 (up to including the 1992-11 updates) do not store absolute paths to working directories internally and therefore do not show this limitation.<ref name="Paul_1997_NWDOSTIP"/> 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&nbsp;bytes. FlexOS, 4680&nbsp;OS and 4690&nbsp;OS support a length of up to 127&nbsp;bytes as well, allowing depths down to 60 levels.<!-- including the root --><ref name="IBM_4690_User_Guide"/> PalmDOS, DR&nbsp;DOS&nbsp;6.0 (since BDOS&nbsp;7.1) and higher, Novell&nbsp;DOS, and OpenDOS sport a MS-DOS-compatible CDS and therefore have the same length limits as MS-DOS/PC&nbsp;DOS.

Each entry can be preceded by "fake entries" to support a [[#VFAT|VFAT long filename]] (LFN); see further below.

Legal characters for DOS short filenames include the following:

* Upper case letters <code>A</code>–<code>Z</code>
* Numbers <code>0</code>–<code>9</code>
* Space (though trailing spaces in either the base name or the extension are considered to be padding and not a part of the file name; also filenames with space in them could not easily be used on the DOS command line prior to Windows&nbsp;95 because of the lack of a suitable [[Escape character|escaping system]]). Another exception are the internal commands <code>[[MKDIR]]</code>/<code>MD</code> and <code>[[RMDIR]]</code>/<code>RD</code> under DR-DOS which accept single arguments and therefore allow spaces to be entered.
* <code>! # $ % & ' ( ) - @ ^ _ ` { } ~ </code>
* Characters 128–228
* Characters 230–255

This excludes the following [[ASCII]] characters:

* <code>" * / : < > ? \ | </code><br>Windows/MS-DOS has no shell [[escape character]]
* <code>+ , . ; = [ ]</code><br/> Allowed in long file names only
* Lower case letters <code>a</code>–<code>z</code><br/>Stored as <code>A</code>–<code>Z</code>; allowed in long file names
* Control characters 0–31
* Character 127 (DEL)

Character 229 ({{mono|[[#DIR_OFS_00h|0xE5]]}}) was not allowed as first character in a filename in DOS 1 and 2 due to its use as free entry marker. A special case was added to circumvent this limitation with DOS 3.0 and higher.

The following additional characters are allowed on Atari's GEMDOS, but should be avoided for compatibility with MS-DOS/PC&nbsp;DOS:

* <code>" + , ; < = > [ ] |</code>

The semicolon (<code>;</code>) should be avoided in <!-- short -->filenames under DR&nbsp;DOS 3.31 and higher, PalmDOS, Novell&nbsp;DOS, OpenDOS, Concurrent&nbsp;DOS<!-- at least since Concurrent&nbsp;DOS&nbsp;XM&nbsp;5.2 and Concurrent&nbsp;DOS&nbsp;386&nbsp;1.1 (in 1987-11 with BDOS 5.x and higher), not sure about earlier issues of Concurrent&nbsp;DOS with BDOS&nbsp;3.1 and higher -->, Multiuser&nbsp;DOS, System&nbsp;Manager and REAL/32<!-- While DOS&nbsp;Plus 1.2, FlexOS, 4680&nbsp;OS, 4690&nbsp;OS support passwords as well, DOS Plus does not support passwords on FAT volumes, and FlexOS, 4680&nbsp;OS, 4690&nbsp;OS do not support the semicolon syntax. Not sure about DOS&nbsp;Plus 2.1. -->, because it may conflict with the syntax to specify file and directory passwords: "<code>...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD</code>". The operating system will strip off one<ref name="Paul_1997_NWDOSTIP"/> (and also two&mdash;since DR-DOS 7.02) semicolons and pending passwords from the <!-- short -->filenames before storing them on disk. (The command processor [[4DOS]] uses semicolons for include lists and requires the semicolon to be doubled for password protected files with any commands supporting wildcards.<ref name="Paul_1997_NWDOSTIP"/>)

The at-sign character (<code>@</code>) 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.<ref name="Paul_1997_NWDOSTIP"/>

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.<ref name="Paul_1997_NWDOSTIP"/>

Under <!-- FlexOS as well? -->IBM 4680&nbsp;OS and 4690&nbsp;OS, the following characters are not allowed in filenames:

* <code>? * : . ; , [ ] ! + = < > " - / \ |</code>

Additionally, the following special characters are not allowed in the first, fourth, fifth and eight character of a filename, as they conflict with the host command processor (HCP) and input sequence table build file names:

* <code>@ # ( ) { } $ &</code>

The DOS file names are in the current [[Code page|OEM character set]]: this can have surprising effects if characters handled in one way for a given code page are interpreted differently for another code page (DOS command <code>[[CHCP (command)|CHCP]]</code>) with respect to lower and upper case, sorting, or validity as file name character.

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

<!-- To be added: Format of 16-byte directory entries used by 86-DOS before 0.42 -->32-byte directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also [[8.3 filename]]):

{| class="wikitable sortable mw-collapsible mw-collapsed"
|-
! Byte offset
! Length (bytes)
! Contents
|-
| style="text-align:right;vertical-align:top;"| 0x00
| style="text-align:right;vertical-align:top;"| 8
| {{anchor|DIR_OFS_00h}}Short file name (padded with spaces)

The first byte can have the following special values:

{| class="wikitable"
|-
! style="width:5em;" | Value
! style="width:90%;" | Description
|-
|0x00
|Entry is available and no subsequent entry is in use. Also serves as an end marker when DOS scans a directory table. (Since MS-DOS 1.25 and PC&nbsp;DOS 2.0, not in earlier versions of MS-DOS<!-- 1.24 or earlier -->, PC&nbsp;DOS<!-- 1.0/1.1 -->, or 86-DOS. Instead, they will treat such entries as allocated. Therefore, this value must not be used as end marker, if a volume should remain accessible under PC&nbsp;DOS 1.0/1.1 as well.<ref group="nb" name="NB_DIRFILL"/><ref name="Microsoft_2014_MSDOS211"/><ref name="Shustek_2014_MS-DOS"/><ref name="Levin_2014_MS-DOS"/>)
|-
|0x05
|Initial character is actually {{mono|0xE5}}. (since DOS&nbsp;3.0)
Under DR&nbsp;DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, {{mono|0x05}} is also used for pending delete files under DELWATCH.<!-- 1.00 and higher--> Once they are removed from the deletion tracking queue, the first character of an erased file is replaced by {{mono|0xE5}}.
|-
|0x2E
|'Dot' entry; either "<code>.</code>" or "<code>..</code>" (since MS-DOS 1.40 and PC&nbsp;DOS 2.0)
|-
|0xE5
|Entry has been previously erased and/or is available.<ref group="nb" name="NB_DIRFILL"/><ref name="Microsoft_2014_MSDOS211"/><ref name="Shustek_2014_MS-DOS"/><ref name="Levin_2014_MS-DOS"/> File [[undelete]] utilities must replace this character with a regular character as part of the undeletion process. See also: {{mono|0x05}}.
The value {{mono|0xE5}} was chosen for this purpose in 86-DOS because 8-inch CP/M floppies came pre-formatted with this value filled and so could be used to store files out of the box.<ref name="Schulman_1994_Undocumented-DOS"/><ref group="nb" name="NB_Magic_E5"/>
|}

Versions of DOS prior to 5.0 start scanning directory tables from the top of the directory table to the bottom. In order to increase chances for successful file undeletion, DOS 5.0 and higher will remember the position of the last written directory entry and use this as a starting point for directory table scans.
|-
| style="text-align:right;vertical-align:top;"| 0x08
| style="text-align:right;vertical-align:top;"| 3
| {{anchor|DIR_OFS_08h}}Short file extension (padded with spaces)
|-
| style="text-align:right;vertical-align:top;"| 0x0B
| style="text-align:right;vertical-align:top;"| 1
| {{anchor|DIR_OFS_0Bh|attributes}}File Attributes

{| class="wikitable"
|-
! style="width:5em;" | Bit
! style="width:6em;" | Mask
! style="width:90%;" | Description
|-
|0
|0x01
|Read Only. (Since DOS 2.0) If this bit is set, the operating system will not allow a file to be opened for modification.

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

The [[Design rule for Camera File system|DCF]] digital camera file system standard utilizes the Read Only attribute to allow directories or individual files ([[DCF object]]s) to be marked as "protected" from deletion by the user.<ref name="DC-009-2010"/>
|-
|1
|0x02
|Hidden. Hides files or directories from normal directory views.

Under DR&nbsp;DOS&nbsp;3.31 and higher, under PalmDOS, Novell&nbsp;DOS, OpenDOS, Concurrent&nbsp;DOS, Multiuser&nbsp;DOS, REAL/32, password protected files and directories also have the hidden attribute set.<ref name="Paul_1997_NWDOSTIP"/> Password-aware operating systems should not hide password-protected files from directory views, even if this bit may be set. The password protection mechanism does not depend on the hidden attribute being set up to including DR-DOS 7.03, but <!-- for future expansion of the scheme - coexistence with VFAT LFN entries -->if the hidden attribute is set, it should not be cleared for any password-protected files.
|-
|2
|0x04
|System. Indicates that the file belongs to the system and must not be physically moved (e.g., during defragmentation), because there may be references into the file using absolute addressing bypassing the file system (boot loaders, kernel images, swap files, extended attributes, etc.).
|-
|3
|0x08
|Volume Label. (Since MS-DOS 1.28 and PC&nbsp;DOS 2.0) Indicates an optional directory volume label, normally only residing in a volume's root directory. Ideally, the volume label should be the first entry in the directory (after reserved entries) in order to avoid problems with VFAT LFNs. If this volume label is not present, some systems<!-- since DOS 4.0 --> may fall back to display the partition volume label instead, if an EBPB is present in the boot sector (not present with some non-bootable block device drivers, and possibly not writeable with boot sector write protection). Even if this volume label is present, partitioning tools like FDISK may display the partition volume label instead. The entry occupies a directory entry but has no file associated with it. Volume labels have a filesize entry of zero.
Pending delete files and directories under DELWATCH have the volume attribute set until they are purged or undeleted.<ref name="Paul_1997_NWDOSTIP"/>
<!-- This bit is also used by Novell NetWare to indicate an executable file, and once set, it cannot be cleared by normal attrib manipulation tools. It is unclear, however, if this is actually used as "execute" bit on FAT disks or only on API level. -->
|-
|4
|0x10
|Subdirectory. (Since MS-DOS 1.40 and PC&nbsp;DOS 2.0) Indicates that the cluster-chain associated with this entry gets interpreted as subdirectory instead of as a file. Subdirectories have a filesize entry of zero.
|-
|5
|0x20
|[[Archive bit|Archive]]. (Since DOS 2.0) Typically set by the operating system as soon as the file is created or modified to mark the file as "dirty", and reset by backup software once the file has been backed up to indicate "pure" state.
|-
|6
|0x40
|[[Device file|Device]] (internally set for character device names found in filespecs, never found on disk), must not be changed by disk tools.<!-- possibly also for pending delete files under DELWATCH? -->
|-
|7
|0x80
|Reserved, must not be changed by disk tools.<!-- Used on API level to access deleted files under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, if DELWATCH is present, but not used for this purpose on disk. Also used on API level by Novell DOS to retrieve the first cluster associated with a file. Also used by NetWare to indicate "sharable" files - unclear, if on API level only, or also on disk. Some clues that FlexOS might use this as a shareable attribute as well, but still needs rechecking. -->
|}

Under DR&nbsp;DOS&nbsp;6.0 and higher, including PalmDOS, Novell&nbsp;DOS and OpenDOS, the volume attribute is set for pending delete files and directories under DELWATCH.<!-- 1.00 and higher -->

An attribute combination of {{mono|0x0F}} is used to designate a [[#VFAT|VFAT long file name]] entry since MS-DOS&nbsp;7.0. Older versions of DOS can mistake this for a directory volume label, as they take the first entry with volume attribute set as volume label. This problem can be avoided if a directory volume label is enforced as part of the format process; for this reason some disk tools explicitly write dummy "<code>NO␠NAME␠␠␠␠</code>" directory volume labels when the user does not specify a volume label.<ref group="nb" name="NB_DRDOS_Volume-Label"/> Since volume labels normally don't have the system attribute set at the same time, it is possible to distinguish between volume labels and VFAT LFN entries.<!-- TBD: Research exact method how different operating systems distinguish between them; while the above method works, possibly more robust methods exist. May not work under DRI systems, which store additional information in volume labels. --> The attribute combination {{mono|0x0F}} could occasionally also occur as part of a valid pending delete file under DELWATCH, however on FAT12 and FAT16 volumes, VFAT LFN entries always have the cluster value at {{mono|[[#VFAT_OFS_1Ah|0x1A]]}} set to {{mono|0x0000}} and the length entry at {{mono|[[#VFAT_OFS_1Ch|0x1C]]}} is never {{mono|0x00000000}}, whereas the entry at {{mono|[[#DIR_OFS_1Ah|0x1A]]}} is always non-zero for pending delete files under DELWATCH. This check does not work on FAT32 volumes.<!-- but additional sanity checks are possible to potentially allow coexistance of DELWATCH on FAT32 without problems. -->
|-
| style="text-align:right;vertical-align:top;"| 0x0C
| style="text-align:right;vertical-align:top;"| 1
| {{anchor|DIR_OFS_0Ch}}
* [[CP/M-86]] and [[DOS&nbsp;Plus]] store user attributes F1'&mdash;F4' here.<ref name="Caldera_1997_DOSSRC"/> (DOS&nbsp;Plus 1.2 with BDOS 4.1 supports passwords only on CP/M media, not on FAT12 or FAT16 media.<ref name="Elliott_1998_DOSPLUS"/> While DOS&nbsp;Plus&nbsp;2.1 supported [[logical sectored FAT]]s with a partition type {{mono|[[Partition type#PID_F2h|0xF2]]}}, FAT16B and FAT32 volumes were not supported by these operation systems. Even if a partition would have been converted to FAT16B it would still not be larger than 32 MB. Therefore, this usage does not conflict with FAT32.IFS, FAT16+ or FAT32+ as they can never occur on the same type of volume.):

{| class="wikitable"
|-
! style="width:5em;"|Bit
! style="width:6em;"|Mask
! style="width:90%;"|Description
|-
|7
|0x80
|F1': Modify default open rules<ref name="Paul_1997_NWDOSTIP"/>
|-
|6
|0x40
|F2': Partial close default<ref name="Paul_1997_NWDOSTIP"/>
|-
|5
|0x20
|F3': Ignore Close Checksum Error<ref name="Paul_1997_NWDOSTIP"/>
|-
|4
|0x10
|F4': Disable checksums<ref name="Paul_1997_NWDOSTIP"/>
|-
|3
|0x08
|Reserved
|-
|2
|0x04
|Delete requires password
|-
|1
|0x02
|Write requires password
|-
|0
|0x01
|Read requires password
|}

* [[MSX-DOS]]&nbsp;2: For a deleted file, the original first character of the filename. For the same feature in various other operating systems, see offset {{mono|[[#DIR_OFS_0Dh|0x0D]]}} if enabled in MSX boot sectors at sector offset {{mono|[[#BSMSX_OFS_026h|0x026]]}}.<!-- not sure if the MSX boot sector flag indicates only that a volume holds files with undelete info, or if it is used to enable this feature in the first place. --> MSX-DOS supported FAT12 volumes only, but third-party extensions for FAT16 volumes exist. Therefore, this usage does not conflict with FAT32.IFS and FAT32+ below.<!-- What about FAT16+? MSX-DOS 2 did not support volumes larger than 32 MB, but what about third-party drivers? --> It does not conflict with the usage for user attributes under CP/M-86 and DOS Plus as well, since they are no longer important for deleted files.
* Windows NT and later versions uses bits 3 and 4 to encode case information (see [[#VFAT|VFAT]]); otherwise 0.<ref name="LongSpec"/>
* DR-DOS 7.0x reserved bits other than 3 and 4<!-- for compatibility with NT --> for internal purposes<!-- for a set of directory entry extensions / heuristics proposed by Matthias R. Paul --> since 1997. The value should be set to 0 by formatting tools and must not be changed by disk tools.<ref name="Paul_1997_NWDOSTIP"/>
* On FAT32 volumes under OS/2 and eComStation the third-party FAT32.IFS driver utilizes this entry as a mark byte to indicate the presence of extra "<code>␠EA.␠SF</code>" files holding [[extended attributes]] with parameter <code>/EAS</code>. Version 0.70 to 0.96 used the magic values {{mono|0x00}} (no EAs), {{mono|0xEA}} (normal EAs) and {{mono|0xEC}} (critical EAs),<ref name="Kelder_FAT32IFS074"/> whereas version 0.97 and higher since 2003-09 use {{mono|0x00}}, {{mono|0x40}} (normal EAs) and {{mono|0x80}} (critical EAs) as bitflags for compatibility with Windows NT.<ref name="Kelder_2003_FAT32IFS0913"/><ref name="Netlabs"/>
|-
| style="text-align:right;vertical-align:top;"| 0x0D
| style="text-align:right;vertical-align:top;"| 1
| {{anchor|DIR_OFS_0Dh}}
*First character of a deleted file under Novell DOS, OpenDOS and DR-DOS 7.02 and higher. A value of {{mono|0xE5}} (229), as set by DELPURGE, will prohibit undeletion by UNDELETE, a value of {{mono|0x00}} will allow conventional undeletion asking the user for the missing first filename character.<ref name="Paul_1997_NWDOSTIP"/> S/DOS 1 and PTS-DOS 6.51<!-- possibly earlier --> and higher also support this feature if enabled with <code>[[SAVENAME (CONFIG.SYS directive)|SAVENAME]]=ON</code> in CONFIG.SYS. For the same feature in MSX-DOS, see offset {{mono|[[#DIR_OFS_0Ch|0x0C]]}}.
*Create time, fine resolution: 10&nbsp;ms units, values from 0 to 199 (since DOS 7.0 with VFAT).

Double usage for create time ms and file char does not create a conflict, since the creation time is no longer important for deleted files.
|-
| style="text-align:right;vertical-align:top;"| 0x0E
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_0Eh}}
* Under DR&nbsp;DOS&nbsp;3.31 and higher including PalmDOS, Novell&nbsp;DOS and OpenDOS<ref name="Caldera_1997_DOSSRC"/> as well as under Concurrent&nbsp;DOS<!-- at least since Concurrent DOS XM 5.2 and Concurrent DOS 386 1.1 (in 1987-11 with BDOS 5.x and higher), not sure about earlier issues of Concurrent DOS with BDOS 3.1 and higher -->, Multiuser&nbsp;DOS, System Manager, and REAL/32 and possibly also under FlexOS, 4680&nbsp;OS, 4690&nbsp;OS<!-- not sure about FlexOS, 4680/4690 --> any non-zero value indicates the password hash of a protected file, directory or volume label.<ref name="Paul_1997_NWDOSTIP"/> The hash is calculated from the first eight characters of a password. If the file operation to be carried out requires a password as per the access rights bitmap stored at offset {{mono|[[#DIR_OFS_14h|0x14]]}}, the system tries to match the hash against the hash code of the currently set global password (by <code>PASSWORD /G</code>) or, if this fails, tries to extract a semicolon-appended password from the filespec passed to the operating system and checks it against the hash code stored here. A set password will be preserved even if a file is deleted and later undeleted.<ref name="Paul_1997_NWDOSTIP"/><!-- at least under DR DOS 6.0 up to DR-DOS 7.03, unknown for newer versions -->
* Create time (since DOS 7.0 with VFAT). The hour, minute and second are encoded according to the following bitmap:
{{anchor|Format_Time}}

{| class="wikitable"
|-
! style="width:5em;"|Bits
! style="width:90%;"|Description
|-
|15-11
|Hours (0–23)
|-
|10-5
|Minutes (0–59)
|-
|4-0
|Seconds/2 (0–29)
|}

:The ''seconds'' is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset {{mono|[[#DIR_OFS_0Dh|0x0D]]}}.

If bits 15-11 > 23 or bits 10-5 > 59 or bits 4-0 > 29 here, or when bits 12-0 at offset {{mono|[[#DIR_OFS_14h|0x14]]}} hold an access bitmap and this is not a FAT32 volume or a volume using OS/2 Extended Attributes<!-- e.g., because the partition uses a secured partition type -->, then this entry actually holds a password hash, otherwise it can be assumed to be a file creation time.
|-
| style="text-align:right;vertical-align:top;"| 0x10
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_10h}}
*[[FlexOS]], [[4680&nbsp;OS]] and [[4690&nbsp;OS]] store a record size in the word<!-- or is it a byte? --> at entry {{mono|[[#DIR_OFS_10h|0x10]]}}.<ref name="Caldera_1997_DOSSRC"/> This is mainly used for their special [[Record-oriented filesystem|database-like file type]]s ''random file'', ''direct file'', ''keyed file'', and ''sequential file''. If the record size is set to 0 (default) or 1, the operating systems assume a record granularity of 1 byte for the file, for which it will not perform record boundary checks in read/write operations.<ref name="IBM_4690_Programming_Guide"/>
*With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified time stamp for pending delete files and directories.<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/> Cleared when file is undeleted or purged. See offset {{mono|[[#DIR_OFS_0Eh|0x0E]]}} for a format [[#Format Time|description]].
*Create date (since DOS 7.0 with VFAT). The year, month and day are encoded according to the following bitmap:
{{anchor|Format_Date}}

{| class="wikitable"
|-
! style="width:5em;"|Bits
! style="width:90%;"|Description
|-
|15-9
|Year (0 = [[Epoch of 1980-01-01|1980]], 119 = [[Year 2100 problem|2099]] supported under DOS/Windows, theoretically up to 127 = [[Year 2108 problem|2107]])
|-
|8-5
|Month (1–12)
|-
|4-0
|Day (1–31)
|}

The usage for creation date for existing files does not conflict with last modified time for deleted files because they are never used at the same time. For the same reason, the usage for the record size of existing files and last modified time of deleted files does not conflict. Creation dates and record sizes cannot be used at the same time, however, both are stored only on file creation and never changed later on, thereby limiting the conflict to FlexOS, 4680 OS and 4690 OS systems accessing files created under foreign operating systems as well as potential display or file sorting problems on systems trying to interpret a record size as creation time.<!-- Additional heuristics can be used to further reduce the risk of a misinterpretation. --> To avoid the conflict, the storage of creation dates should be an optional feature of operating systems supporting it.
|-
| style="text-align:right;vertical-align:top;"| 0x12
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_12h}}
*FlexOS<!-- at least since 2.x -->, 4680&nbsp;OS, 4690&nbsp;OS, Multiuser DOS<!-- 5.x and higher -->, System Manager, REAL/32 and DR&nbsp;DOS&nbsp;6.0 and higher with multi-user security enabled use this field to store owner IDs.<ref name="Paul_1997_NWDOSTIP"/> Offset {{mono|0x12}} holds the user ID, {{mono|0x13}} the group ID of a file's creator.<ref name="Caldera_1997_DOSSRC"/><!-- at least under FlexOS, 4680&nbsp;OS, 4690&nbsp;OS, not sure if Concurrent DOS stored owner IDs as well -->
:In multi-user versions, system access requires a logon with account name and password, and the system assigns group and user IDs to running applications according to the previously set up and stored authorization info and inheritance rules. For 4680&nbsp;OS and 4690&nbsp;OS, group ID 1 is reserved for the system, group ID 2 for vendor, group ID 3 for the default user group. Background applications started by users have a group ID 2 and user ID 1, whereas operating system background tasks have group IDs 1 or 0 and user IDs 1 or 0. [[IBM 4680 BASIC]] and applications started as primary or secondary always get group ID 2 and user ID 1. When applications create files, the system will store their user ID and group ID and the required permissions with the file.<ref name="IBM_4690_Programming_Guide"/>

*With DELWATCH&nbsp;2.00 and higher under Novell&nbsp;DOS&nbsp;7, OpenDOS&nbsp;7.01 and DR-DOS&nbsp;7.02 and higher, this entry is used to store the last modified date stamp for pending delete files and directories.<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/> Cleared when file is undeleted or purged.  See offset {{mono|[[#DIR_OFS_10h|0x10]]}} for a format [[#Format Date|description]].
*Last access date (since DOS 7.0 if [[ACCDATE (CONFIG.SYS directive)|ACCDATE]] enabled in CONFIG.SYS for the corresponding drive);<ref name="Microsoft_2006_ACCDATE"/><ref name="Paul_1997_NWDOSTIP"/> see offset {{mono|[[#DIR_OFS_10h|0x10]]}} for a format [[#Format Date|description]].

The usage for the owner IDs of existing files does not conflict with last modified date stamp for deleted files because they are never used at the same time.<ref name="Paul_1997_NWDOSTIP"/> The usage of the last modified date stamp for deleted files does not conflict with access date since access dates are no longer important for deleted files.  However, owner IDs and access dates cannot be used at the same time.
|-
| style="text-align:right;vertical-align:top;"| 0x14
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_14h}}
*High two bytes of first cluster number in FAT32; with the low two bytes stored at offset {{mono|[[#DIR_OFS_1Ah|0x1A]]}}.
*{{anchor|access rights}}Access rights bitmap for world/group/owner read/write/execute/delete protection for password protected files, directories (or volume labels) under DR&nbsp;DOS&nbsp;3.31<!-- at least 3.41 and higher --> and higher, including PalmDOS, Novell&nbsp;DOS and OpenDOS,<ref name="Caldera_1997_DOSSRC"/> and under FlexOS,<ref name="Caldera_1997_DOSSRC"/><!-- 2.x --> 4680&nbsp;OS, 4690&nbsp;OS, Concurrent&nbsp;DOS<!-- at least CDOS 386 and CDOS XM -->, Multiuser&nbsp;DOS<!-- 5.x -->, System Manager, and REAL/32.
:Typical values stored on a single-user system are {{mono|0x0000}} (<code>PASSWORD /N</code> for all access rights "RWED"), {{mono|0x0111}} (<code>PASSWORD /D</code> for access rights "RW?-"), {{mono|0x0555}} (<code>PASSWORD /W</code> for access rights "R-?-") and {{mono|0x0DDD}} (<code>PASSWORD /R</code> for files or <code>PASSWORD /P</code> for directories for access rights "--?-").<ref name="Paul_1997_NWDOSTIP"/> Bits 1, 5, 9, 12-15 will be preserved when changing access rights. If execute bits are set on systems other than FlexOS, 4680&nbsp;OS or 4690&nbsp;OS, they will be treated similar to read bits. (Some versions of PASSWORD allow to set passwords on volume labels (<code>PASSWORD /V</code>) as well.)
:Single-user systems calculate the most restrictive rights of the three sets (DR&nbsp;DOS up to 5.0 used bits 0-3 only) and check if any of the requested file access types requires a permission and if a file password is stored.<ref name="Paul_1997_NWDOSTIP"/> If not,<!-- detail needs to be rechecked --> file access is granted. Otherwise the stored password is checked against an optional global password provided by the operating system and an optional file password provided as part of the filename separated by a semicolon (not under FlexOS, 4680&nbsp;OS, 4690&nbsp;OS). If neither of them is provided, the request will fail. If one of them matches, the system will grant access (within the limits of the normal file attributes, that is, a read-only file can still not be opened for write this way), otherwise fail the request.<ref name="Paul_1997_NWDOSTIP"/>
:Under FlexOS, 4680&nbsp;OS and 4690&nbsp;OS the system assigns group and user IDs to applications when launched. When they request file access, their group and user IDs are compared with the group and user IDs of the file to be opened. If both IDs match, the application will be treated as file owner. If only the group ID matches, the operating system will grant group access to the application, and if the group ID does not match as well, it will grant world access. If an application's group ID and user ID are both 0, the operating system will bypass security checking. Once the permission class has been determined, the operating system will check if any of the access types of the requested file operation requires a permission according to the stored bitflags of the selected class owner, group or world in the file's directory entry. Owner, group and world access rights are independent and do not need to have diminishing access levels.<!-- Does not seem to be very logical, but that's what is stated in the IBM docs. Not sure about this in Multiuser DOS --> Only, if none of the requested access types require a permission, the operating system will grant access, otherwise it fails.
:If multiuser file / directory password security is enabled<!-- apparently not under FlexOS/4680 OS/4690 OS, but under Multiuser DOS, REAL/32 and DR-DOS with multi-user security? --> the system will not fail at this stage but perform the password checking mechanism for the selected permission class similar to the procedure described above. With multi-user security loaded many utilities since DR DOS 6.0 will provide an additional <code>/U:name</code><!-- up to 12 characters --> parameter.<ref name="Paul_1997_NWDOSTIP"/>

:File access rights bitmap:<!-- These values also represent the CX bit flags at INT 21h/AX=4302h --><ref name="Caldera_1997_SYS"/>

{| class="wikitable"
|-
! style="width:5em;"|Bit
! style="width:6em;"|Mask
! style="width:90%;"|Description
|-
|0
|0x0001
|Owner delete/rename/attribute change requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|1
|0x0002
|Owner execute requires permission (FlexOS, 4680&nbsp;OS, 4690&nbsp;OS only)<ref name="Caldera_1997_SYS"/>
|-
|2
|0x0004
|Owner write/modify requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|3
|0x0008
|Owner read/copy requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|4
|0x0010
|Group delete/rename/attribute change requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|5
|0x0020
|Group execute requires permission (FlexOS, 4680&nbsp;OS, 4690&nbsp;OS only)<ref name="Caldera_1997_SYS"/>
|-
|6
|0x0040
|Group write/modify requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|7
|0x0080
|Group read/copy requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|8
|0x0100
|World delete/rename/attribute change requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|9
|0x0200
|World execute requires permission (FlexOS, 4680&nbsp;OS, 4690&nbsp;OS only)<ref name="Caldera_1997_SYS"/>
|-
|10
|0x0400
|World write/modify requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|11
|0x0800
|World read/copy requires permission<ref name="Paul_1997_NWDOSTIP"/><ref name="Caldera_1997_DOSSRC"/><ref name="Caldera_1997_SYS"/>
|-
|12-15
|
|bits must be set to 0 during format and must not be modified by disk tools later on;<ref name="Paul_1997_NWDOSTIP"/> bit&nbsp;15 is used internally,<ref name="Caldera_1997_SYS"/> but not on disk
|}
:File renames require either write or delete rights, [[IBM 4680 BASIC]] CHAIN requires execute rights.

*[[Extended Attributes]] handle (used by [[OS/2]] 1.2 and higher as well as by Windows NT) in FAT12 and FAT16; first cluster of EA file or 0, if not used.<ref name="Paul_1997_NWDOSTIP"/><ref name="Eager_2000_EA"/> A different method to store extended attributes has been devised for FAT32 volumes, see FAT32.IFS under offset {{mono|[[#DIR_OFS_0Ch|0x0C]]}}.

The storage of the high two bytes of the first cluster in a file on FAT32 partially conflicts with access rights bitmaps.
|-
| style="text-align:right;vertical-align:top;"| 0x16
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_16h}}
*Last modified time (since [[PC&nbsp;DOS 1.1]]/[[MS-DOS 1.20]]); see offset {{mono|[[#DIR_OFS_0Eh|0x0E]]}} for a format [[#Format Time|description]].
*Under Novell&nbsp;DOS, OpenDOS and DR-DOS&nbsp;7.02 and higher, this entry holds the deletion time of pending delete files or directories under DELWATCH&nbsp;2.00 or higher. The last modified time stamp is copied to {{mono|[[#DIR_OFS_10h|0x10]]}} for possible later restoration.<ref name="Paul_1997_NWDOSTIP"/> See offset {{mono|[[#DIR_OFS_0Eh|0x0E]]}} for a format [[#Format Time|description]].
|-
| style="text-align:right;vertical-align:top;"| 0x18
| style="text-align:right;vertical-align:top;"| 2
| {{anchor|DIR_OFS_18h}}
*Last modified date; see offset {{mono|[[#DIR_OFS_10h|0x10]]}} for a format [[#Format Date|description]].
*Under Novell&nbsp;DOS, OpenDOS and DR-DOS&nbsp;7.02 and higher, this entry holds the deletion date of pending delete files or directories under DELWATCH 2.00 or higher. The last modified date stamp is copied to {{mono|[[#DIR_OFS_12h|0x12]]}} for possible later restoration.<ref name="Paul_1997_NWDOSTIP"/> See offset {{mono|[[#DIR_OFS_10h|0x10]]}} for a format [[#Format Date|description]].
|-
| style="text-align:right;"| 0x1A
| style="text-align:right;"| 2
| {{anchor|DIR_OFS_1Ah}}Start of file in clusters in FAT12 and FAT16. Low two bytes of first cluster in FAT32; with the high two bytes stored at offset {{mono|[[#DIR_OFS_14h|0x14]]}}.

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

VFAT LFN entries also have this entry set to 0; on FAT12 and FAT16 volumes this can be used as part of a detection mechanism to  distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.
|-
| style="text-align:right;vertical-align:top;"| 0x1C
| style="text-align:right;vertical-align:top;"| 4
| {{anchor|DIR_OFS_1Ch}}File size in bytes. Entries with the Volume Label or Subdirectory flag set should have a size of 0.

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

{{anchor|DIR-DISTRIBUTION}}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:<ref name="IBM_4690_OS_Distribution_Attributes_1"/>

# Local: Don't distribute file but keep on local controller only.<ref group="nb" name="NB_IBM_Local"/>
# Mirror file on update: Distribute file to server only when file is updated.
# Mirror file on close: Distribute file to server only when file is closed.
# Compound file on update: Distribute file to all controllers when file is updated.
# Compound file on close: Distribute file to all controllers when file is closed.<ref name="IBM_4690_OS_Distribution_Attributes_2"/><!-- These operating systems also support a file CRC and file-based encryption http://www.google.com/patents/US20100058157 -->
{{anchor|DIR-INCOMPATIBLE}}Some incompatible extensions found in some operating systems include:

{| class="wikitable sortable mw-collapsible mw-collapsed"
|-
! style="width:7em;" | Byte offset
! style="width:7em;" | Length (bytes)
! style="width:14em;" | System
! style="width:90%;" | Description
|-
| style="text-align:right;"| 0x0C
| style="text-align:right;"| 2
|[[RISC OS]]
|File type, {{mono|0x0000}}–{{mono|0x0FFF}}
|-
| style="text-align:right;"| 0x0C
| style="text-align:right;"| 4
|[http://mdfs.net/Apps/Filing/DOSFS Petrov DOSFS]
|File load address
|-
| style="text-align:right;"| 0x0E
| style="text-align:right;"| 2
|[[ANDOS]]
|File address in the memory
|-
| style="text-align:right;"| 0x10
| style="text-align:right;"| 4
|[http://mdfs.net/Apps/Filing/DOSFS Petrov DOSFS]
|File execution address
|}

== Size limits ==
The 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 (1, 2, 4, ..., 128). For the typical value of 512 bytes per sector:
<blockquote>
<poem style="overflow: auto">
FAT12 requirements : 3 sectors on each copy of FAT for every 1,024 clusters
FAT16 requirements : 1 sector on each copy of FAT for every 256 clusters
FAT32 requirements : 1 sector on each copy of FAT for every 128 clusters

FAT12 range : 1 to 4,084 clusters : 1 to 12 sectors per copy of FAT
FAT16 range : 4,085 to 65,524 clusters : 16 to 256 sectors per copy of FAT
FAT32 range : 65,525 to 268,435,444 clusters : 512 to 2,097,152 sectors per copy of FAT

FAT12 minimum : 1 sector per cluster × 1 clusters = 512 bytes (0.5 KiB)
FAT16 minimum : 1 sector per cluster × 4,085 clusters = 2,091,520 bytes (2,042.5 KB)
FAT32 minimum : 1 sector per cluster × 65,525 clusters = 33,548,800 bytes (32,762.5 KB)

FAT12 maximum : 64 sectors per cluster × 4,084 clusters = 133,824,512 bytes (≈ 127 MB)
[FAT12 maximum : 128 sectors per cluster × 4,084 clusters = 267,694,024 bytes (≈ 255 MB)]

FAT16 maximum : 64 sectors per cluster × 65,524 clusters = 2,147,090,432 bytes (≈2,047 MB)
[FAT16 maximum : 128 sectors per cluster × 65,524 clusters = 4,294,180,864 bytes (≈4,095 MB)]

FAT32 maximum : 8 sectors per cluster × 268,435,444 clusters = 1,099,511,578,624 bytes (≈1,024 GB)
FAT32 maximum : 16 sectors per cluster × 268,173,557 clusters = 2,196,877,778,944 bytes (≈2,046 GB)
[FAT32 maximum : 32 sectors per cluster × 134,152,181 clusters = 2,197,949,333,504 bytes (≈2,047 GB)]
[FAT32 maximum : 64 sectors per cluster × 67,092,469 clusters = 2,198,486,024,192 bytes (≈2,047 GB)]
[FAT32 maximum : 128 sectors per cluster × 33,550,325 clusters = 2,198,754,099,200 bytes (≈2,047 GB)]
</poem>
</blockquote>
:'''Legend:''' 268435444+3 is {{mono|0x0FFFFFF7}}, because FAT32 version 0 uses only 28 bits in the 32-bit cluster numbers, cluster numbers {{mono|0x0FFFFFF7}} up to {{mono|0x0FFFFFFF}} flag bad clusters or the end of a file, cluster number 0 flags a free cluster, and cluster number 1 is not used.<ref name="two" /> Likewise 65524+3 is {{mono|0xFFF7}} for FAT16, and 4084+3 is {{mono|0xFF7}} for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 ({{mono|0x01}}), the biggest value is 128 ({{mono|0x80}}). Lines in square brackets indicate the unusual cluster size 128, and for FAT32 the bigger than necessary cluster sizes 32 or 64.<ref name="Microsoft_2007_KB184006"/>

Because each FAT32 entry occupies 32 bits (4 bytes) the maximal number of clusters (268435444) requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is {{mono|0x200000}}, 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 ({{mono|0x28}}) or 41 ({{mono|0x29}}). 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 <code>[[RMDIR]]</code>/<code>RD</code> command removes the initial "<code>.</code>" (this directory) and "<code>..</code>" (parent directory) entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12,<!-- explanation unclear --> 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 (on a RAM disk unused) boot code and the magic {{mono|0x55 0xAA}} at the end of all boot sectors. On [[Windows NT]] the smallest supported sector size is 128.

On [[Windows NT]] operating systems the <code>FORMAT</code> command options <code>/A:128K</code> and <code>/A:256K</code> correspond to the maximal cluster size <code>0x80</code> (128) with a sector size 1024 and 2048, respectively. For the common sector size 512 <code>/A:64K</code> yields 128 sectors per cluster.

Both editions of each ECMA-107<ref name="Ecma-107" /> and ISO/IEC 9293<ref name="ISO_9293_1994"/><ref name="ISO_9293_1987"/> specify a ''Max Cluster Number'' <code>MAX</code> determined by the formula <code>MAX=1+trunc((<abbr title="total sectors">TS</abbr>-<abbr title="sectors in system area">SSA</abbr>)/<abbr title="sectors per cluster">SC</abbr>)</code>, and reserve cluster numbers <code>MAX+1</code> up to 4086 ({{mono|0xFF6}}, FAT12) and later 65526 ({{mono|0xFFF6}}, FAT16) for future standardization.

Microsoft's EFI FAT32 specification<ref name="efi"/> 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 ({{mono|0xFFF}}, {{mono|0xFFFF}} or {{mono|0x0FFFFFFF}}).<!-- it is still unclear, if the file system driver actually uses the value stored here as EOC marker or not. --> The entries for cluster numbers 0 and 1 end at a byte boundary even for FAT12, e.g., {{mono|0xF9FFFF}} for media descriptor {{mono|0xF9}}.

The first data cluster is 2,<ref name="two"/> and consequently the last cluster <code>MAX</code> gets number <code>MAX+1</code>. This results in data cluster numbers 2...4085 ({{mono|0xFF5}}) for FAT12, 2...65525 ({{mono|0xFFF5}}) for FAT16, and 2...268435445 ({{mono|0x0FFFFFF5}}) for FAT32.

The only available values reserved for future standardization are therefore {{mono|0xFF6}} (FAT12) and {{mono|0xFFF6}} (FAT16). As noted below "less than 4085" is also used for Linux implementations,<ref name="max4084"/> or as [[Microsoft]]'s FAT specification puts it:<ref name="efi"/>

<blockquote cite="http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc">...when it says &lt;, it does not mean &lt;=. 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 "&lt;" signs are not wrong."</blockquote>

== Fragmentation ==
<span id="SuperFAT"></span><!-- Header "Fragmentation" used in local links. -->

The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition.<ref name="dgaiotnhpfs"/> 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 (computing)|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 (with parts having to be loaded into memory first in particular on large volumes) 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., [[High Performance File System|HPFS]] or [[exFAT]], use [[free space bitmap]]s 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 (as is done in [[Unix]] file systems). 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 (such as with DOS) 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 (Microsoft)|Raymond Chen]] for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "<code>[[dir (command)|DIR]]</code>" operation, which always displays the free disk space as the last line.<ref name="TechNet on FAT32"/> 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<!-- as on ATX-style PCs the former power-switch was replaced by a soft-button, which is under BIOS and OS control -->, on plain DOS systems<!-- as most DOS issues have no true "shutdown" command --> and some battery-powered consumer products.

With the huge cluster sizes (16 KB, 32 KB, 64 KB) forced by larger FAT partitions, [[internal fragmentation]] in form of disk space waste by file slack due to [[cluster overhang]] (as files are rarely exact multiples of cluster size) 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.<ref name="Bell_1990_SuperFAT"/><ref name="Bridges_1996_SuperFAT"/> 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.<!-- a low-performance read-only implementation of FAT12/FAT16/FAT32 can be done in as little as 512 bytes of code and 1 KB of data -->

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.<ref name="Williams_1992_MS-DOS-Reference"/> 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.<ref name="Williams_1992_MS-DOS-Reference"/> These pointers are initialized to point to the start of the FATs after bootup,<ref name="Williams_1992_MS-DOS-Reference"/> but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the [[#FS Information Sector|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.<ref name="Williams_1992_MS-DOS-Reference"/> 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 {{mono|0xE5}} since DOS 3.0.<ref name="Schulman_1994_Undocumented-DOS"/> 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.<ref name="Chappell_1994_DOS-Internals"/>

Since DOS 3.3 the operating system provides means to improve the performance of file operations with <code>[[FASTOPEN]]</code> by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC&nbsp;DOS)<!-- 48 bytes per entry --> or hash tables (DR-DOS)<!-- 2 bytes per entry -->, 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.<ref name="Bell_1990_SuperFAT"/><ref name="Bridges_1996_SuperFAT"/> 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 (computer)|fragmentation]] of FAT file systems also result from performance limitations of the underlying block [[device driver]]s, 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 ([[Native Command Queuing|only one outstanding input/output request at a time]] and [[Programmed input/output|no DMA transfers]]) 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 [[Expanded memory|EMS]] or [[Extended memory|XMS]] memory and sometimes providing adaptive caching strategies<!-- e.g., NWCACHE --> or even run in [[protected mode]] through [[DOS Protected Mode Services|DPMS]]<!-- e.g., NWCACHE --> or [[Helix Cloaking|Cloaking]]<!-- e.g., Helix' cloaked variant of SMARTDRV --> 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 (if present) 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.
{{See also|File system fragmentation}}

== VFAT long file names ==
<span id="VFAT"></span><!-- Header "VFAT long file names" used in local links. -->

[[File:VFAT directory entries.png|thumb|upright=1.5|FAT32 directory structure with three files, two of which use VFAT long file names.]]

[[VFAT]] Long File Names (LFNs) 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 (yielding {{mono|0x0F}}), 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&nbsp;DOS&nbsp;6.0 (1991) and higher. It is also similar to a method publicly discussed to store long filenames on Ataris and under Linux in 1992.<ref name="_1992_LFNs"/><ref name="Torvalds_1992_LFNs"/>

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 (if a volume label did not already exist).<!-- based on design discussions with Windows 95 team members --><ref group="nb" name="NB_DRDOS_Volume-Label"/>

Each phony entry can contain up to 13 [[UCS-2]] characters (26 bytes) by using fields in the record which contain file size or time stamps (but not the starting cluster field, for compatibility with disk utilities, the starting cluster field is set to a value of 0. See [[8.3 filename]] for additional explanations). Up to 20 of these 13-character entries may be chained, supporting a maximum length of 255 UCS-2 characters.<ref name="LongSpec" /><!-- Technically, up to 31 would be possible. -->

If the position of the LFN's last character is '''not''' at a directory entry boundary (13, 26, 39, ...), then a {{mono|0x0000}} terminator is added in the next character position. Then, if that terminator is also not at the boundary, remaining character positions are filled with {{mono|0xFFFF}}. No directory entry containing a lone terminator will exist.

LFN entries use the following format:

{| class="wikitable sortable mw-collapsible"
|-
! style="width:7em;" | Byte offset
! style="width:7em;" | Length (bytes)
! style="width:90%;" | Description
|-
| style="text-align:right;"| [[#DIR_OFS_00h|0x00]]
| style="text-align:right;"| 1
| {{anchor|VFAT_OFS_00h}}Sequence Number (bit 6: last logical, first physical LFN entry, bit 5: 0; bits 4-0: number {{mono|0x01}}..{{mono|0x14}} ({{mono|0x1F}}), deleted entry: {{mono|0xE5}}<!-- or just bit 7 set? -->)
|-
| style="text-align:right;"| 0x01
| style="text-align:right;"| 10
| {{anchor|VFAT_OFS_01h}}Name characters (five [[UCS-2]] characters)
|-
| style="text-align:right;"| [[#DIR_OFS_0Bh|0x0B]]
| style="text-align:right;"| 1
| {{anchor|VFAT_OFS_0Bh}}Attributes (always {{mono|0x0F}})
|-
| style="text-align:right;"| [[#DIR_OFS_0Ch|0x0C]]
| style="text-align:right;"| 1
| {{anchor|VFAT_OFS_0Ch}}Type (always {{mono|0x00}} for VFAT LFN, other values reserved for future use; for special usage of bits 4 and 3 in SFNs see further up)
|-
| style="text-align:right;"| [[#DIR_OFS_0Dh|0x0D]]
| style="text-align:right;"| 1
| {{anchor|VFAT_OFS_0Dh}}Checksum of DOS file name
|-
| style="text-align:right;"| [[#DIR_OFS_0Eh|0x0E]]
| style="text-align:right;"| 12
| {{anchor|VFAT_OFS_0Eh}}Name characters (six [[UCS-2]] characters)
|-
| style="text-align:right;"| [[#DIR_OFS_1Ah|0x1A]]
| style="text-align:right;"| 2
| {{anchor|VFAT_OFS_1Ah}}First cluster (always {{mono|0x0000}})
|-
| style="text-align:right;"| [[#DIR_OFS_1Ch|0x1C]]
| style="text-align:right;"| 4
| {{anchor|VFAT_OFS_1Ch}}Name characters (two [[UCS-2]] characters)
|}

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 ({{mono|0x40}}) 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 {{mono|0xE5}} is used to indicate that the entry is deleted.<!-- originally, this sentence stated "bit 7 set" instead of value 0xE5, but I doubt this. Does someone know an implementation depending on bit 7 set only? -->

On FAT12 and FAT16 volumes, testing for the values at {{mono|[[#VFAT_OFS_1Ah|0x1A]]}} to be zero and at {{mono|[[#VFAT_OFS_1Ch|0x1C]]}} to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH.<!-- some sophisticated tests necessary on FAT32 -->

For example, a filename like "File with very long filename.ext" would be formatted like this:

{| class="wikitable sortable mw-collapsible"
|-
! style="width:14em;"|Sequence&nbsp;number
! style="width:90%;"|Entry data
|-
| style="text-align:right;"| 0x43
|align="left"|"me.ext"
|-
| style="text-align:right;"| 0x02
|align="left"|"y long filena"
|-
| style="text-align:right;"| 0x01
|align="left"|"File with ver"
|-
| style="text-align:right;"| ???
|align="left"|Normal 8.3 entry
|}

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. (pFCBName is a pointer to the name as it appears in a regular directory entry, i.e. the first eight characters are the filename, and the last three are the extension. The dot is implicit. Any unused space in the filename is padded with space characters (ASCII {{mono|0x20}}). For example, "Readme.txt" would be "<code>README␠␠TXT</code>".)
<syntaxhighlight lang="c">
unsigned char lfn_checksum(const unsigned char *pFCBName)
{
   int i;
   unsigned char sum = 0;

   for (i = 11; i; i--)
      sum = ((sum & 1) << 7) + (sum >> 1) + *pFCBName++;

   return sum;
}
</syntaxhighlight>

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 {{mono|[[#DIR_OFS_0Ch|0x0C]]}} 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 "<code>example.TXT</code>" or "<code>HELLO.txt</code>" but not "<code>Mixed.txt</code>". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (Windows 95 / 98 / 98 SE / ME) 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 (source: kernel 2.6.18 <code>/fs/fat/dir.c</code> and <code>fs/vfat/namei.c</code>); the mount option <code>shortname</code> determines whether this feature is used when writing.<ref name="Linux_Mount"/>

== See also ==
* [[Comparison of file systems]]
* [[Drive letter assignment]]
* [[exFAT]]
* [[Extended Boot Record]] (EBR)
* [[FAT filesystem and Linux]]
* [[List of file systems]]
* [[Master Boot Record]] (MBR)
* [[Partition type]]
* [[Timeline of DOS operating systems]]
* [[Transaction-Safe FAT File System]]
* [[Turbo FAT]]
* [[Volume Boot Record]] (VBR)

== Notes ==
<references group="nb">
<ref group="nb" name="NB_WIN98_WINCOM">If a volume's dirty shutdown flag is still cleared on startup, the volume was not properly unmounted. This would, for example, cause Windows 98 WIN.COM to start [[SCANDISK]] in order to check for and repair potential logical file system errors. If the bad sector flag is cleared, it will force a surface scan to be carried out as well. This can be disabled by setting AUTOSCAN=0 in the [OPTIONS] section in [[MSDOS.SYS]] file.</ref>
<ref group="nb" name="NB_Magic_E5">This is the reason, why {{mono|0xE5}} had a special meaning in directory entries.<!-- <ref name="Schulman_1994_Undocumented-DOS"/> --></ref>
<ref group="nb" name="NB_Format_Wipe">One utility providing an option to specify the desired format filler value for hard disks is DR-DOS' FDISK&nbsp;R2.31 with its optional wipe parameter <code>/W:246</code>. In contrast to other [[FDISK]] utilities, DR-DOS FDISK is not only a partitioning tool, but can also format freshly created partitions as [[FAT12]], [[FAT16]] or [[FAT32]]. This reduces the risk to accidentally format wrong volumes.</ref>
<ref group="nb" name="NB_MAGIC_EB">For maximum compatibility with MS-DOS/PC&nbsp;DOS and DR-DOS, operating systems trying to determine a floppy disk's format should test on all mentioned opcode sequences at sector offset {{mono|0x000}} in ''addition'' to looking for a valid media descriptor byte at sector offset {{mono|0x015}} before assuming the presence of a [[#BPB|BPB]]. Although PC&nbsp;DOS&nbsp;1.0 floppy disks do not contain a BPB, they start with {{mono|0xEB}} as well, but do not show a {{mono|0x90}} at offset {{mono|0x002}}. PC&nbsp;DOS&nbsp;1.10 floppy disks even start with {{mono|0xEB&nbsp;0x??&nbsp;0x90}}, although they still do not feature a BPB. In both cases, a test for a valid media descriptor at offset {{mono|0x015}} would fail (value {{mono|0x00}} instead of valid media descriptors {{mono|0xF0}} and higher). If these tests fail, DOS checks for the presence of a [[#media|media descriptor]] byte in the first byte of the [[#CLUST_0|first FAT]] in the sector following the boot sector (logical sector 1 on FAT12/FAT16 floppies).</ref>
<ref group="nb" name="NB_Magic_AA55">The signature at offset {{mono|0x1FE}} in boot sectors is {{mono|0x55 0xAA}}, that is {{mono|0x55}} at offset {{mono|0x1FE}} and {{mono|0xAA}} at offset {{mono|0x1FF}}. Since [[little-endian]] representation must be assumed in the context of [[IBM PC]] compatible machines, this can be written as 16-bit word {{mono|0xAA55}} in programs for [[Intel x86|x86]] processors (note the swapped order), whereas it would have to be written as {{mono|0x55AA}} in programs for other CPU architectures using a [[big-endian]] representation. Since this has been mixed up numerous times in books and even in original Microsoft reference documents,<!-- one example of many: https://technet.microsoft.com/en-us/library/cc977219.aspx as of 2012-01-14 --> this article uses the offset-based byte-wise on-disk representation to avoid any possible misinterpretation.</ref>
<ref group="nb" name="NB_Magic_1234">The [[Modular sum|checksum]] entry in [[Atari ST|Atari]] boot sectors holds the alignment value, not the [[Magic number (programming)|magic value]] itself. The magic value {{mono|0x1234}} is not stored anywhere on disk. In contrast to [[Intel x86]] processors, the [[Motorola 68000|Motorola 680x0]] processors as used in Atari machines use a [[big-endian]] memory representation and therefore a big-endian representation must be assumed when calculating the checksum. As a consequence of this, for checksum verification code running on x86 machines, pairs of bytes must be swapped before the 16-bit addition.</ref>
<ref group="nb" name="NB_DRDOS_Logical-Sectoring">DR-DOS is able to boot off FAT12/FAT16 logical sectored media with logical sector sizes up to 1024 bytes.</ref>
<ref group="nb" name="NB_MAGIC_FF0">See other links for special precautions in regard to occurrences of a cluster value of {{mono|0xFF0}} on FAT12 volumes under MS-DOS/PC DOS 3.3 and higher.</ref>
<ref group="nb" name="NB_DRDOS_Volume-Label">To avoid potential misinterpretation of directory volume labels with VFAT LFN entries by non-VFAT aware operating systems, the DR-DOS&nbsp;7.07 FDISK and FORMAT tools are known to explicitly write dummy "<code>NO␠NAME␠␠␠␠</code>" directory volume labels if the user skips entering a volume label. The operating system would internally default to return the same string if no directory volume label could be found in the root of a volume, but without a real volume label stored as the first entry (after the directory entries), older operating systems could erroneously pick up VFAT LFN entries instead.</ref>
<ref group="nb" name="NB_IBM_Local">This [[IBM 4680 OS]] and [[IBM 4690 OS|4690 OS]] distribution attribute type must have an on-disk bit value of 0 as files fall back to this type when attributes get lost accidentally.</ref>
<ref group="nb" name="NB_DRDOS_BIOS-Name">In order to support the coexistence of DR-DOS with PC DOS and multiple parallel installations of DR-DOS, the extension of the default "<code>IBMBIO␠␠COM</code>" boot file name can be changed using the <code>SYS /DR:ext</code> option, where ext represents the new extension. Other potential DR-DOS boot file names to be expected in special scenarios are "<code>DRBIOS␠␠SYS</code>", "<code>DRDOS␠␠␠SYS</code>", "<code>IO␠␠␠␠␠␠SYS</code>", "<code>JO␠␠␠␠␠␠SYS</code>".</ref>
<ref group="nb" name="NB_INT21_DATETIME">The following DOS functions return these register values:
INT 21h/AH=2Ah "Get system date" returned values: CX = year ([[Epoch of 1980-01-01|1980]]..[[Year 2100 problem|2099]]), DH = month (1..12), DL = day (1..31).
INT 21h/AH=2Ch "Get system time" returned values: CH = hour (0..23), CL = minute (0..59), DH = second (0..59), DL = 1/100 seconds (0..99).</ref>
<ref group="nb" name="NB_Hybrid_Disk">Windows XP has been observed to create such hybrid disks when reformatting FAT16B formatted ZIP-100 disks to FAT32 format. The resulting volumes were FAT32 by format, but still used the FAT16B EBPB. (It is unclear how Windows determines the location of the root directory on FAT32 volumes, if only a FAT16 EBPB was used.)</ref>
<ref group="nb" name="NB_DIRFILL">Some versions of [[FORMAT]] since [[MS-DOS 1.25]] and [[PC DOS 2.0]] supported an option <code>/O</code> (for ''old'') to fill the first byte of all [[#DIR|directory entries]] with {{mono|0xE5}} instead of utilizing the end marker {{mono|0x00}}. Thereby. the volume remained accessible under [[PC DOS 1.0]]-[[PC DOS 1.1|1.1]]<!-- and MS-DOS 1.24 and earlier, including 86-DOS -->, while formatting took somewhat longer and newer versions of DOS could not take advantage of the considerable speed-up caused by using the end marker {{mono|0x00}}.</ref>
</references><references group="nb"/><!-- {{Reflist|group="nb"}} -->

== References ==
{{reflist|refs=
<ref name="Brouwer_2002_FAT">{{cite web | url = http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html#ss1.3 | title = FAT | date = 2002-09-20 | author = Andries Brouwer | author-link = Andries Brouwer | access-date = 2012-01-11 | archive-date = 2017-12-17  | archive-url = https://web.archive.org/web/20171217052324/http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html#ss1.3 | url-status = live }}</ref>
<ref name="Microsoft_1984_MS-DOS_3.1_Ref">{{cite book
|title=Microsoft MS-DOS 3.1 Programmierhandbuch in englischer Sprache
|trans-title=Microsoft MS-DOS 3.1 Programmer's Reference Manual in English
|author=<!--Staff writer(s); no by-line.-->
|publisher=Markt & Technik Verlag
|place=München
|publication-date=1986
|year=1984
|isbn=3-89090-368-1
|id=8411-310-02, 036-014-012
|quote=In regard to the jump instruction at the start of a boot sector: "Determine if the first byte of the boot sector is an E9H or EBIT<!-- what does EBIT mean here? --> (the first byte of a 3-byte NEAR or 2-byte short jump) or an EBH (the first byte of a 2-byte jump followed by a NOP). If so, a BPB is located beginning at offset 3."}} (NB. This book contains many errors.)</ref>
<ref name="Ecma-107">{{cite web | url = http://www.ecma-international.org/publications/standards/Ecma-107.htm | title = Volume and File Structure of Disk Cartridges for Information Interchange | work = Standard ECMA-107 (2nd ed., June 1995) | publisher = [[Ecma International|ECMA]] | year = 1995 | access-date = 2011-07-30 | archive-date = 2018-10-07  | archive-url = https://web.archive.org/web/20181007174227/http://ecma-international.org/publications/standards/Ecma-107.htm | url-status = live }}</ref>
<ref name="ISO_9293_1994">{{cite web | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21273 | title = Information technology -- Volume and file structure of disk cartridges for information interchange | work = ISO/IEC 9293:1994 | publisher = [[International Organization for Standardization|ISO]] catalogue | year = 1994 | access-date = 2012-01-06 | archive-date = 2012-01-17  | archive-url = https://web.archive.org/web/20120117180640/http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21273 | url-status = live }}</ref>
<ref name="ISO_9293_1987">{{cite web | url = http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=16948 | title = Information processing -- Volume and file structure of flexible disk cartridges for information interchange | work = ISO 9293:1987 | publisher = [[International Organization for Standardization|ISO]] catalogue | year = 1987 | access-date = 2012-01-06 | archive-date = 2012-01-17  | archive-url = https://web.archive.org/web/20120117181849/http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=16948 | url-status = live }}</ref>
<ref name="Duncan_1988_MS-DOS_Encyclopedia">{{Cite book |title=The MS-DOS Encyclopedia: versions 1.0 through 3.2 |author-first1=Ray |author-last1=Duncan |author-first2=Steve |author-last2=Bostwick |author-first3=Keith |author-last3=Burgoyne |author-first4=Robert A. |author-last4=Byers |author-first5=Thom |author-last5=Hogan |author-first6=Jim |author-last6=Kyle |author-first7=Gordon |author-last7=Letwin |author-link7=Gordon Letwin |author-first8=Charles |author-last8=Petzold |author-link8=Charles Petzold |author-first9=Chip |author-last9=Rabinowitz |author-first10=Jim |author-last10=Tomlin |author-first11=Richard |author-last11=Wilton |author-first12=Van |author-last12=Wolverton |author-first13=William |author-last13=Wong |author-first14=JoAnne |author-last14=Woodcock |contribution=Technical advisors |contributor-first1=Mark |contributor-last1=Zbikowski |contributor-link1=Mark Zbikowski |contributor-first2=Paul |contributor-last2=Allen |contributor-link2=Paul Allen |contributor-first3=Steve |contributor-last3=Ballmer |contributor-link3=Steve Ballmer |contributor-first4=Reuben |contributor-last4=Borman |contributor-first5=Rob |contributor-last5=Borman |contributor-first6=John |contributor-last6=Butler |contributor-first7=Chuck |contributor-last7=Carroll |contributor-first8=Mark |contributor-last8=Chamberlain |contributor-first9=David |contributor-last9=Chell |contributor-first10=Mike |contributor-last10=Colee |contributor-first11=Mike |contributor-last11=Courtney |contributor-first12=Mike |contributor-last12=Dryfoos |contributor-first13=Rachel |contributor-last13=Duncan |contributor-first14=Kurt |contributor-last14=Eckhardt |contributor-first15=Eric |contributor-last15=Evans |contributor-first16=Rick |contributor-last16=Farmer |contributor-first17=Bill |contributor-last17=Gates |contributor-link17=Bill Gates |contributor-first18=Michael |contributor-last18=Geary |contributor-first19=Bob |contributor-last19=Griffin |contributor-first20=Doug |contributor-last20=Hogarth |contributor-first21=James W. |contributor-last21=Johnson |contributor-first22=Kaamel |contributor-last22=Kermaani |contributor-first23=Adrian |contributor-last23=King |contributor-first24=Reed |contributor-last24=Koch |contributor-first25=James |contributor-last25=Landowski |contributor-first26=Chris |contributor-last26=Larson |contributor-first27=Thomas |contributor-last27=Lennon |contributor-first28=Dan |contributor-last28=Lipkie |contributor-first29=Marc |contributor-last29=McDonald |contributor-link29=Marc McDonald |contributor-first30=Bruce |contributor-last30=McKinney |contributor-first31=Pascal |contributor-last31=Martin |contributor-first32=Estelle |contributor-last32=Mathers |contributor-first33=Bob |contributor-last33=Matthews <!-- |contributor-link33=Robert Matthews (scientist)??? --> |contributor-first34=David |contributor-last34=Melin 
|contributor-first35=Charles |contributor-last35=Mergentime |contributor-first36=Randy |contributor-last36=Nevin |contributor-first37=Dan |contributor-last37=Newell |contributor-first38=Tani |contributor-last38=Newell |contributor-first39=David |contributor-last39=Norris |contributor-first40=Mike |contributor-last40=O'Leary |contributor-first41=Bob |contributor-last41=O'Rear |contributor-link41=Bob O'Rear |contributor-first42=Mike |contributor-last42=Olsson |contributor-first43=Larry |contributor-last43=Osterman |contributor-first44=Ridge |contributor-last44=Ostling |contributor-first45=Sunil |contributor-last45=Pai |contributor-first46=Tim |contributor-last46=Paterson |contributor-link46=Tim Paterson |contributor-first47=Gary |contributor-last47=Perez |contributor-first48=Chris |contributor-last48=Peters |contributor-first49=Charles |contributor-last49=Petzold |contributor-link49=Charles Petzold |contributor-first50=John |contributor-last50=Pollock |contributor-first51=Aaron |contributor-last51=Reynolds |contributor-link51=Aaron R. Reynolds |contributor-first52=Darryl |contributor-last52=Rubin |contributor-first53=Ralph |contributor-last53=Ryan
|contributor-first54=Karl |contributor-last54=Schulmeisters |contributor-first55=Rajen |contributor-last55=Shah |contributor-first56=Barry |contributor-last56=Shaw |contributor-first57=Anthony |contributor-last57=Short |contributor-first58=Ben |contributor-last58=Slivka |contributor-first59=Jon |contributor-last59=Smirl |contributor-first60=Betty |contributor-last60=Stillmaker |contributor-first61=John |contributor-last61=Stoddard |contributor-first62=Dennis |contributor-last62=Tillman |contributor-first63=Greg |contributor-last63=Whitten |contributor-first64=Natalie |contributor-last64=Yount |contributor-first65=Steve |contributor-last65=Zeck |date=1988 |edition=Completely reworked |publisher=[[Microsoft Press]] |location=Redmond, Washington, USA |isbn=1-55615-049-0 |lccn=87-21452 |oclc=16581341}} (xix+1570 pages; 26&nbsp;cm) (NB. This edition was published in 1988 after extensive rework of the withdrawn 1986 first edition by a different team of authors. [https://www.pcjs.org/pubs/pc/reference/microsoft/mspl13/msdos/encyclopedia/] {{Webarchive|url=https://web.archive.org/web/20181014053041/https://www.pcjs.org/pubs/pc/reference/microsoft/mspl13/msdos/encyclopedia/ |date=2018-10-14  }})</ref><!-- While mostly based on DOS 3.2, this book has an appendix covering changes introduced with DOS 3.3 -->
<ref name="Schulman_1994_Undocumented-DOS">{{cite book |author-first1=Andrew |author-last1=Schulman |author-first2=Ralf D. |author-last2=Brown |author-link2=Ralf D. Brown |author-first3=David |author-last3=Maxey |author-first4=Raymond J. |author-last4=Michels |author-first5=Jim |author-last5=Kyle |title=Undocumented DOS: A programmer's guide to reserved MS-DOS functions and data structures - expanded to include MS-DOS 6, Novell DOS and Windows 3.1 |publisher=[[Addison Wesley]] |edition=2 |date=1994 |orig-year=November 1993<!-- first printing --> |isbn=0-201-63287-X |location=Reading, Massachusetts |page=[https://archive.org/details/undocumenteddosp00andr_0/page/11 11] |url=https://archive.org/details/undocumenteddosp00andr_0/page/11 }} (xviii+856+vi pages, 3.5"-floppy) Errata: [https://web.archive.org/web/20190417215556/https://www.cs.cmu.edu/afs/cs/user/ralf/pub/books/UndocumentedDOS/errata.ud2][https://web.archive.org/web/20190417212906/https://www.pcjs.org/pubs/pc/programming/Undocumented_DOS/#errata-2nd-edition]</ref>
<ref name="Norton2">[[Peter Norton]] (1986). ''Inside the IBM PC, Revised and Enlarged'', Brady. {{ISBN|0-89303-583-1}}, p. 157.</ref>
<ref name="efi">{{cite web | url = http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc | title = Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format | publisher = [[Microsoft]] | date = 2000-12-06 | access-date = 2011-07-03 | archive-date = 2021-07-23  | archive-url = https://web.archive.org/web/20210723100623/http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc | url-status = live }}</ref>
<ref name="max4084">{{cite web | url = http://www.win.tue.nl/~aeb/linux/fs/fat/fat-2.html | title = FAT under Linux | author = Andries Brouwer | author-link = Andries Brouwer | access-date = 2014-05-20  | archive-date = 2014-07-01  | archive-url = https://web.archive.org/web/20140701193815/http://www.win.tue.nl/~aeb/linux/fs/fat/fat-2.html | url-status = live }}</ref>
<ref name="Chappell_1994_DOS-Internals">{{cite book |title=DOS Internals |author-first=Geoff |author-last=Chappell |editor-first1=Andrew |editor-last1=Schulman |editor-first2=Amorette |editor-last2=Pedersen |date=January 1994 |edition=1st printing, 1st |series=The Andrew Schulman Programming Series |publisher=[[Addison Wesley Publishing Company]] |isbn=978-0-201-60835-9 }} (xxvi+738+iv pages, 3.5"-floppy [https://web.archive.org/web/20190421200111/https://gopher.tildeverse.org/gopher.viste.fr/9/programming/PC/DOS/DOS%2520Internals/DOS_Internals.zip][https://web.archive.org/web/20200222111608/https://www.pcjs.org/pubs/pc/programming/DOS_Internals/]) Errata: [https://web.archive.org/web/20200222111742/http://www.geoffchappell.com/notes/dos/internals/][https://web.archive.org/web/20200222111853/https://gopher.tildeverse.org/gopher.viste.fr/1/programming/PC/DOS/DOS%2520Internals/crtdrvr][https://web.archive.org/web/20200222111945/https://gopher.tildeverse.org/gopher.viste.fr/1/programming/PC/DOS/DOS%2520Internals/xmswatch]</ref>
<ref name="Microsoft_2003_KB75131">{{cite web | url = http://support.microsoft.com/kb/75131 | title = Standard Floppy Disk Formats Supported by MS-DOS | publisher = Microsoft Help and Support | date = 2003-05-12 | access-date = 2012-09-11 | archive-date = 2015-01-09  | archive-url = https://web.archive.org/web/20150109055410/http://support.microsoft.com/kb/75131 | url-status = live }}</ref>
<ref name="Microsoft_2005_BB457122">{{cite web
|publisher=[[Microsoft TechNet]]
|url=https://technet.microsoft.com/en-us/library/bb457122.aspx
|title=Troubleshooting Disks and File Systems
|date=2005-11-05
|access-date=2014-06-15
|archive-date=2014-06-07 
|archive-url=https://web.archive.org/web/20140607081108/http://technet.microsoft.com/en-us/library/bb457122.aspx
|url-status=live
}}</ref>
<ref name="Microsoft_1998_CC768180">{{cite web | url = https://technet.microsoft.com/en-us/library/cc768180.aspx | title = Windows 98 Resource Kit - Chapter 10 - Disks and File Systems | publisher = [[Microsoft TechNet]] | year = 1998 | access-date = 2012-07-16 | archive-date = 2012-05-01  | archive-url = https://web.archive.org/web/20120501150154/http://technet.microsoft.com/en-us/library/cc768180.aspx | url-status = live }}</ref>
<ref name="Microsoft_2007_KB184006">{{cite web | url = http://support.microsoft.com/kb/184006 | title = Limitations of FAT32 File System | quote = Clusters cannot be 64&nbsp;kilobytes or larger | date = 2007-03-26 | publisher = [[Microsoft Knowledge Base]] | access-date = 2011-08-21 | archive-date = 2011-08-15  | archive-url = https://web.archive.org/web/20110815101217/http://support.microsoft.com/kb/184006/ | url-status = live }}</ref>
<ref name="Microsoft_1987_DOS33Ref">Microsoft (1987-07). ''MS-DOS 3.3 Programmer's Reference.''</ref>
<ref name="GB4">{{cite web | url = https://technet.microsoft.com/en-us/library/cc938937.aspx | title = File Systems | year = 2001 | publisher = [[Microsoft TechNet]] | access-date = 2011-07-31 | archive-date = 2011-08-12  | archive-url = https://web.archive.org/web/20110812044910/http://technet.microsoft.com/en-us/library/cc938937.aspx | url-status = live }}</ref>
<ref name="IBM_4690_Programming_Guide">IBM. ''4690 OS Programming Guide Version 5.2'', IBM document SC30-4137-01, 2007-12-06 ([ftp://ftp.software.ibm.com/software/retail/pubs/sw/opsys/4690/ver5r2/bsi1_PG_mst.pdf] {{Webarchive|url=https://web.archive.org/web/20220125063705/ftp://ftp.software.ibm.com/software/retail/pubs/sw/opsys/4690/ver5r2/bsi1_PG_mst.pdf |date=2022-01-25  }}).</ref>
<ref name="Sedory_2005_PCDOS10">Daniel B. Sedory. ''The Boot Sector of IBM Personal Computer DOS Version 1.00 (1981)''. 2005-08-02 ([http://thestarman.narod.ru/DOS/ibm100/Boot.htm#AuthID] {{Webarchive|url=https://web.archive.org/web/20140521070658/http://thestarman.narod.ru/DOS/ibm100/Boot.htm#AuthID |date=2014-05-21  }}).</ref>
<ref name="Sedory_2005_PCDOS11">Daniel B. Sedory. ''The Boot Sector of IBM Personal Computer DOS Version 1.10 (1982)''. 2005-07-29 ([http://thestarman.narod.ru/DOS/ibm110/Boot.htm#AuthID] {{Webarchive|url=https://web.archive.org/web/20140521070008/http://thestarman.narod.ru/DOS/ibm110/Boot.htm#AuthID |date=2014-05-21  }}).</ref>
<ref name="Caldera_1997_DOSSRC_69h">Caldera (1997). ''Caldera OpenDOS Machine Readable Source Kit 7.01''. The DISK.ASM file in the machine readable source kit shows that DR-DOS tests on value {{mono|0x69}} as well.</ref>
<ref name="Paul_2002_OEM">{{cite newsgroup |title=Need DOS 6.22 (Not OEM) |author-first=Matthias R. |author-last=Paul |date=2002-02-20 |newsgroup=alt.msdos.programmer |url=https://groups.google.com/d/msg/alt.msdos.programmer/MAv9LuYQjs8/HuYCph4KsQYJ |access-date=2006-10-14 |url-status=live |archive-url=https://archive.today/20170909145248/https://groups.google.com/forum/%23!msg/alt.msdos.programmer/MAv9LuYQjs8/HuYCph4KsQYJ |archive-date=2017-09-09}}</ref>
<ref name="Bass_1994_OEM">{{cite newsgroup |title=Cluster Size |author-first=Wally |author-last=Bass |date=1994-02-14 |newsgroup=comp.os.msdos.programmer |url=https://groups.google.com/d/msg/comp.os.msdos.programmer/ZGE7qkh4eI0/1vssg3Yt3nkJ |access-date=2006-10-14 |url-status=live |archive-url=https://archive.today/20170909144921/https://groups.google.com/forum/%23!msg/comp.os.msdos.programmer/ZGE7qkh4eI0/1vssg3Yt3nkJ |archive-date=2017-09-09}}</ref>
<ref name="Williams_1992_MS-DOS-Reference">Dave Williams (1992). ''Programmer's Technical Reference for MSDOS and the IBM PC''. DOSREF, Shareware version 01/12/1992. {{ISBN|1-878830-02-3}}. ([http://www.o3one.org/hwdocs/bios_doc/dosref22.html] {{Webarchive|url=https://web.archive.org/web/20140520012509/http://www.o3one.org/hwdocs/bios_doc/dosref22.html |date=2014-05-20  }}, accessed on 2012-01-08). Comment: The author mentions that DOS 4.0 checks the OEM label, but denies that DOS 3.2 checks it as well (although it does).</ref>
<ref name="Paul_2004_OEM">{{cite web |title=NOVOLTRK.REG |author-first=Matthias R. |author-last=Paul |date=2004-08-25 |work=www.drdos.org |url=http://www.ibiblio.org/pub/micro/pc-stuff/freedos/win9x/NOVOLTRK.ZIP |access-date=2011-12-17 |url-status=dead |archive-url=https://web.archive.org/web/20160304124755/http://www.ibiblio.org/pub/micro/pc-stuff/freedos/win9x/NOVOLTRK.ZIP |archive-date=2016-03-04}} [https://web.archive.org/web/20051111015142/http://public.www.planetmirror.com/pub/freedos/win9x/]</ref>
<ref name="IBM_1983_PC">IBM (1983). ''IBM PC Technical Reference Handbook''. Comment: Includes a complete listing of the ROM BIOS source code of the original IBM PC.</ref>
<ref name="Jankowski_1992_Atari">Hans-Dieter Jankowski, Dietmar Rabich, Julian F. Reschke (1992). ''Atari Profibuch ST-STE-TT''. Sybex, 4th edition, 12th batch. {{ISBN|3-88745-888-5}}, {{ISBN|978-3-88745-888-1}}.</ref>
<ref name="Seagate">Seagate Technologies, "The Transition to Advanced Format 4K Sector Hard Drives (archived by Wayback Machine @Archive.org)", 2010 ([https://web.archive.org/web/20110902031330/http://seagate.com/docs/pdf/whitepaper/tp613_transition_to_4k_sectors.pdf]).</ref>
<ref name="msdosref">{{cite book | title = Microsoft MS-DOS Programmer's Reference: version 5.0 | publisher = Microsoft press | year = 1991 | isbn = 1-55615-329-5 | url = https://archive.org/details/isbn_9781556153297 }}</ref>
<ref name="AB">{{cite web | url = http://www.win.tue.nl/~aeb/linux/fs/fat/fat.html | title = The FAT file system | date = 2002-09-20 | author = Andries Brouwer | author-link = Andries Brouwer | access-date = 2011-10-16 | archive-date = 2011-10-06  | archive-url = https://web.archive.org/web/20111006033548/http://www.win.tue.nl/~aeb/linux/fs/fat/fat.html | url-status = live }}</ref>
<ref name="Microsoft_2003_KB140418">{{cite web
| url = http://support.microsoft.com/kb/140418
| title = Detailed Explanation of FAT Boot Sector
| date = 2003-12-06
| work = [[Microsoft Knowledge Base]]
| access-date = 2011-10-16
| archive-date = 2011-11-28 
| archive-url = https://web.archive.org/web/20111128233605/http://support.microsoft.com/kb/140418
| url-status = live
}}</ref>
<ref name="Microsoft_2014_MSDOS211">{{cite web
|first1=Tim
|last1=Paterson
|author-link1=Tim Paterson
|author2=Microsoft
|title=Microsoft DOS V1.1 and V2.0: /msdos/v20source/FORMAT.TXT
|url=http://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|publisher=[[Computer History Museum]], [[Microsoft]]
|date=2013-12-19<!-- 2014-03-25 -->
|orig-year=1983<!-- 1983-05-17 -->
|access-date=2014-03-25
|archive-date=2019-08-14 
|archive-url=https://web.archive.org/web/20190814021325/https://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|url-status=live
}} (NB. While the publishers claim this would be MS-DOS 1.1 and 2.0, it actually is [[SCP MS-DOS 1.25]] and a mixture of [[Altos MS-DOS 2.11]] and [[TeleVideo PC DOS 2.11]].)</ref>
<ref name="Microsoft_2014_Altos">{{cite news
|first1=Tim
|last1=Paterson
|author-link1=Tim Paterson
|author2=Microsoft
|title=Microsoft DOS V1.1 and V2.0: /msdos/v20source/SKELIO.TXT, /msdos/v20source/HRDDRV.ASM
|newspaper=CHM
|url=http://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|publisher=[[Computer History Museum]], [[Microsoft]]
|date=2013-12-19<!-- 2014-03-25 -->
|orig-year=1983<!-- 1983-05-17 -->
|access-date=2014-03-25
|archive-date=2019-08-14 
|archive-url=https://web.archive.org/web/20190814021325/https://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|url-status=live
}} (NB. While the publishers claim this would be MS-DOS 1.1 and 2.0, it actually is [[SCP MS-DOS 1.25]] and a mixture of [[Altos MS-DOS 2.11]] and [[TeleVideo PC DOS 2.11]].)</ref>
<ref name="Microsoft_2014_DEVDRIV">{{cite web
|first1=Tim
|last1=Paterson
|author-link1=Tim Paterson
|author2=Microsoft
|title=Microsoft DOS V1.1 and V2.0: /msdos/v20source/DEVDRIV.txt
|url=http://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|publisher=[[Computer History Museum]], [[Microsoft]]
|date=2013-12-19<!-- 2014-03-25 -->
|orig-year=1983<!-- 1983-05-17 -->
|access-date=2014-03-25
|archive-date=2019-08-14 
|archive-url=https://web.archive.org/web/20190814021325/https://www.computerhistory.org/atchm/microsoft-research-license-agreement-msdos-v1-1-v2-0/
|url-status=live
}} (NB. While the publishers claim this would be MS-DOS 1.1 and 2.0, it actually is [[SCP MS-DOS 1.25]] and a mixture of [[Altos MS-DOS 2.11]] and [[TeleVideo PC DOS 2.11]].)</ref>
<ref name="Shustek_2014_MS-DOS">{{Cite web
|url=http://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/
|title=Microsoft MS-DOS early source code
|series=Software Gems: The Computer History Museum Historical Source Code Series
|first=Len
|last=Shustek
|date=2014-03-24
|access-date=2014-03-29
|archive-date=2019-08-10 
|archive-url=https://web.archive.org/web/20190810045508/https://www.computerhistory.org/atchm/microsoft-ms-dos-early-source-code/
|url-status=live
}} (NB. While the author claims this would be MS-DOS 1.1 and 2.0, it actually is [[SCP MS-DOS 1.25]] and a mixture of [[Altos MS-DOS 2.11]] and [[TeleVideo PC DOS 2.11]].)</ref>
<ref name="Levin_2014_MS-DOS">{{cite web
|url=http://blogs.technet.com/b/microsoft_blog/archive/2014/03/25/microsoft-makes-source-code-for-ms-dos-and-word-for-windows-available-to-public.aspx
|title=Microsoft makes source code for MS-DOS and Word for Windows available to public
|date=2014-03-25
|first=Roy
|last=Levin
|work=Official Microsoft Blog
|access-date=2014-03-29
|archive-url=https://web.archive.org/web/20140328094124/http://blogs.technet.com/b/microsoft_blog/archive/2014/03/25/microsoft-makes-source-code-for-ms-dos-and-word-for-windows-available-to-public.aspx
|archive-date=28 March 2014
|url-status=dead
}} (NB. While the author claims this would be MS-DOS 1.1 and 2.0, it actually is [[SCP MS-DOS 1.25]] and a mixture of [[Altos MS-DOS 2.11]] and [[TeleVideo PC DOS 2.11]].)</ref>
<ref name="BoynePollard_2010_BPB">{{cite web
|title=All about BIOS parameter blocks
|url=http://jdebp.eu./FGA/bios-parameter-block.html
|first=Jonathan
|last=de Boyne Pollard
|date=2010
|orig-year=2006
|access-date=2014-06-02
|work=Frequently Given Answers
|archive-date=2016-08-26 
|archive-url=https://web.archive.org/web/20160826032950/http://jdebp.eu/FGA/bios-parameter-block.html
|url-status=live
}}</ref>
<ref name="DEW_FAT-Bootsector">{{cite web | title = Detailed Explanation of FAT Boot Sector | publisher = DEW Associates Corporation | year = 2002 | url = http://www.dewassoc.com/kbase/hard_drives/boot_sector.htm | access-date = 2011-10-16 | archive-date = 2011-09-26  | archive-url = https://web.archive.org/web/20110926222842/http://www.dewassoc.com/kbase/hard_drives/boot_sector.htm | url-status = live }}</ref>
<ref name="Sedory_2001_DirtyFlags">Daniel B. Sedory. ''Detailed Notes on the "Dirty Shutdown Flag" under MS-Windows''. 2001-12-04. ([http://thestarman.narod.ru/DOS/DirtyShutdownFlag.html] {{Webarchive|url=https://web.archive.org/web/20140521070007/http://thestarman.narod.ru/DOS/DirtyShutdownFlag.html |date=2014-05-21  }}).</ref>
<ref name="IBM_4690_User_Guide">IBM. ''4690 OS User's Guide Version 5.2'', IBM document SC30-4134-01, 2008-01-10 ([ftp://ftp.software.ibm.com/software/retail/pubs/sw/opsys/4690/ver5r2/bsf1_UG_mst.pdf] {{Webarchive|url=https://web.archive.org/web/20220125063641/ftp://ftp.software.ibm.com/software/retail/pubs/sw/opsys/4690/ver5r2/bsf1_UG_mst.pdf |date=2022-01-25  }}).</ref>
<ref name="Elliott_1998_DOSPLUS">John C. Elliott (1998). ''CP/M 4.1 disc formats''. ([http://www.seasip.demon.co.uk/Cpm/format41.html] {{Webarchive|url=https://web.archive.org/web/20140826000634/http://www.seasip.demon.co.uk/Cpm/format41.html |date=2014-08-26  }}): "CP/M 4.1 (DOS Plus [1.2]) allows the use of two file systems - CP/M and DOS. The version [...] supplied with the Amstrad PC1512 cannot handle larger floppies than 360k (CP/M) / 1.2Mb (DOS), or larger hard drive partitions than 32Mb. [...] The DOS file system can be either FAT12 or FAT16. The format is exactly as in PCDOS 2.11, except: Byte 0Ch of the directory entry [...] holds the four "user attributes" F1'-F4' [...] DRDOS-style passwords are not supported."</ref><!-- Does this apply to DOS Plus 2.1 as well? -->
<ref name="Elliott_1998_DOSPLUS2">John C. Elliott (1998). ''DOSPLUS disc formats''. ([http://www.seasip.demon.co.uk/Cpm/fat_formats.html] {{Webarchive|url=https://web.archive.org/web/20130607011638/http://www.seasip.demon.co.uk/Cpm/fat_formats.html |date=2013-06-07  }}).</ref>
<ref name="USERPROMPT_1985_PORTDOS">''PORT-DOS - Userprompt Guide for Apricot Portable''. User-Prompt Guides, UK ([http://actapricot.org/support/apricot_user_prompt_guide_portable.pdf] {{Webarchive|url=https://web.archive.org/web/20130522115003/http://actapricot.org/support/apricot_user_prompt_guide_portable.pdf |date=2013-05-22  }}).</ref>
<ref name="YELPIG_BBCMASTER">''The BBC Master 512''. Yellow Pig's BBC Computer Pages ([http://www.cowsarenotpurple.co.uk/bbccomputer/master512/format.html] {{Webarchive|url=https://web.archive.org/web/20140521050201/http://www.cowsarenotpurple.co.uk/bbccomputer/master512/format.html |date=2014-05-21  }}).</ref>
<ref name="LongSpec">{{cite web | url = http://www.teleport.com/~brainy/lfn.htm | title = Long Filename Specification | author = vinDaci | date = 1998-01-06 | access-date = 2007-03-13 | archive-url = https://web.archive.org/web/20010420094054/http://www.teleport.com/~brainy/lfn.htm | archive-date = 20 April 2001 | url-status = dead }}</ref>
<ref name="Kelder_FAT32IFS074">Henk Kelder. ''FAT32.TXT for FAT32.IFS version 0.74''. ({{cite web |url=http://macarlo.com/fat32v074.htm |title=@Macarlo, Inc |access-date=2012-01-14 |url-status=dead |archive-url=https://web.archive.org/web/20120330171510/http://macarlo.com/fat32v074.htm |archive-date=2012-03-30}}). Comment: This older version of the README file still discusses the old {{mono|0xEA}} and {{mono|0xEC}} magic values.</ref>
<ref name="Kelder_2003_FAT32IFS0913">Henk Kelder (2003). ''FAT32.TXT for FAT32.IFS version 0.9.13." ([http://svn.netlabs.org/repos/fat32/branches/fat32-0.9/src/fat32.txt] {{Webarchive|url=https://web.archive.org/web/20220125063646/http://svn.netlabs.org/repos/fat32/branches/fat32-0.9/src/fat32.txt |date=2022-01-25  }}): "This byte [...] is not modified while running [[Windows 95]] and neighter by [[SCANDISK]] or [[DEFRAG]]. [...] If another program sets the value to {{mono|0x00}} for a file that has [[extended attributes|EAs]] these EAs will no longer be found using DosFindFirst/Next calls only. The other [[OS/2]] calls for retrieving EAs (DosQueryPathInfo, DosQueryFileInfo and DosEnumAttribute) do not rely on this byte. Also the opposite could [...] occur. [...] In this situation only the performance of directory scans will be decreased. Both situations [...] are corrected by [[CHKDSK]]".</ref>
<ref name="Netlabs">Netlabs. ''FAT32.IFS Wiki and Sources''. ([http://svn.netlabs.org/fat32/wiki/WikiStart] {{Webarchive|url=https://web.archive.org/web/20130511121722/http://svn.netlabs.org/fat32/wiki/WikiStart |date=2013-05-11  }}).</ref>
<ref name="Paul_1997_NWDOSTIP">{{cite book |title=NWDOS-TIPs &mdash; Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds |series=MPDOSTIP |author-first=Matthias R. |author-last=Paul |date=1997-07-30 |orig-year=1994-05-01 |edition=3 |language=de |url=http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |access-date=2012-01-11 |url-status=live |archive-url=https://web.archive.org/web/20161105172944/http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm |archive-date=2016-11-05}} (NB. NWDOSTIP.TXT is a comprehensive work on [[Novell DOS 7]] and [[OpenDOS 7.01]], including the description of many undocumented features and internals. It is part of the author's yet larger MPDOSTIP.ZIP<!-- still named TIPS_MP.ZIP between 1991 and 1996-11 --> collection maintained up to 2001 and distributed on many sites at the time. The provided link points to a HTML-converted older version of the file.) [https://web.archive.org/web/20190601152204/https://www.sac.sk/download/text/mpdostip.zip<!-- A yet older version 155 from 1997-05-13 of the 1997-07-15 distribution archive. -->]</ref>
<ref name="Caldera_1997_DOSSRC">Caldera (1997). ''Caldera OpenDOS Machine Readable Source Kit 7.01''. The FDOS.EQU file in the machine readable source kit has equates for the corresponding directory entries.</ref>
<ref name="Microsoft_2006_ACCDATE">Microsoft (2006-11-15). [http://support.microsoft.com/kb/135481/EN-US Windows 95 CD-ROM CONFIG.TXT File] {{Webarchive|url=https://archive.today/20130128224809/http://support.microsoft.com/kb/135481/EN-US |date=2013-01-28  }} Article 135481, Revision: 1.1, retrieved 2011-12-22: "For each hard disk, specifies whether to record the date that files are last accessed. Last access dates are turned off for all drives when your computer is started in safe mode, and are not maintained for floppy disks by default. Syntax: <code>[[ACCDATE (CONFIG.SYS directive)|ACCDATE]]=drive1+|- [drive2+|-]...</code>"</ref>
<ref name="Caldera_1997_SYS">{{cite book |publisher=[[Caldera, Inc.]] |date=August 1997 |title=OpenDOS Developer's Reference Series &mdash; System and Programmer's Guide &mdash; Programmer's Guide |id=Caldera Part No. 200-DODG-003 |url=http://www.drdos.net/documentation/sysprog/httoc.htm |url-status=dead |archive-url=https://web.archive.org/web/20171007025631/http://www.drdos.net/documentation/sysprog/httoc.htm |archive-date=7 October 2017 |access-date=20 May 2014 }} (Printed in the UK.)</ref>
<ref name="Eager_2000_EA">Bob Eager, Tavi Systems (2000-10-28). ''Implementation of extended attributes on the FAT file system''. ([http://www.tavi.co.uk/os2pages/eadata.html] {{Webarchive|url=https://web.archive.org/web/20060613212300/http://www.tavi.co.uk/os2pages/eadata.html |date=2006-06-13  }}).</ref>
<ref name="IBM_4690_OS_Distribution_Attributes_1">IBM (2003). ''Information about 4690&nbsp;OS unique file distribution attributes'', IBM document R1001487, 2003-07-30. ({{cite web |url=http://www-01.ibm.com/support/docview.wss?uid=pos1R1001487 |title=IBM Information about 4690 OS unique file distribution attributes - United States |access-date=2014-05-20 |url-status=dead |archive-url=https://web.archive.org/web/20140521070339/http://www-01.ibm.com/support/docview.wss?uid=pos1R1001487 |archive-date=2014-05-21}}): "[...] file types are stored in the "Reserved bits" portion of the PC-DOS file directory structure [...] only 4690 respects and preserves these attributes. Various non-4690 operating systems take different actions if these bits are turned on [...] when copying from a diskette created on a 4690 system. [...] PC-DOS and Windows 2000 Professional will copy the file without error and zero the bits. OS/2 [...] 1.2 [...] will refuse to copy the file unless [...] first run CHKDSK /F on the file. After [...] CHKDSK, it will copy the file and zero the bits. [...] when [...] copy [...] back to the 4690 system, [...] file will copy as a local file."</ref>
<ref name="IBM_4690_OS_Distribution_Attributes_2">IBM. ''4690 save and restore file distribution attributes''. IBM document R1000622, 2010-08-31 ({{cite web |url=http://www-01.ibm.com/support/docview.wss?uid=pos1R1000622 |title=IBM 4690 save and restore file distribution attributes - United States |access-date=2014-05-20 |url-status=dead |archive-url=https://web.archive.org/web/20140521070536/http://www-01.ibm.com/support/docview.wss?uid=pos1R1000622 |archive-date=2014-05-21}}).</ref>
<ref name="Linux_Mount">{{cite web | url = http://linux.die.net/man/8/mount | title = mount(8): mount file system | work = Linux man page | access-date = 2014-05-20  | archive-date = 2014-05-05  | archive-url = https://web.archive.org/web/20140505235926/http://linux.die.net/man/8/mount | url-status = live }}</ref>
<ref name="two">{{cite web | quote = The numbering starts with 2; the first two numbers, 0 and 1, are reserved. | url = http://www.patersontech.com/dos/Byte/InsideDos.htm#InsideDos_44 | title = An Inside Look at MS-DOS | year = 1983 | publisher = [[Byte (magazine)|Byte]] | author = [[Tim Paterson]] | access-date = 2011-07-18 | url-status = dead | archive-url = https://web.archive.org/web/20110720115141/http://patersontech.com/Dos/Byte/InsideDos.htm#InsideDos_44 | archive-date = 2011-07-20}}</ref>
<ref name="dgaiotnhpfs">{{cite web | url = http://cd.textfiles.com/megademo2/INFO/OS2_HPFS.TXT | title = Design goals and implementation of the new High Performance File System | last = Duncan | first = Ray | year = 1989 | publisher = Microsoft Systems Journal | volume = 4 | issue = 5 | access-date = 2014-05-20  | archive-date = 2011-07-16  | archive-url = https://web.archive.org/web/20110716214405/http://cd.textfiles.com/megademo2/INFO/OS2_HPFS.TXT | url-status = live }} [NB. This particular text file has a number of OCR errors; e.g., "Ray" is the author's correct name; not 'Roy' as the text shows.]</ref>
<ref name="TechNet on FAT32">{{cite web | last = Chen | first = Raymond | author-link = Raymond Chen (Microsoft) | date = July 2006 | url = http://www.microsoft.com/technet/technetmag/issues/2006/07/WindowsConfidential/ | title = Microsoft TechNet: A Brief and Incomplete History of FAT32 | publisher = Microsoft TechNet Magazine | access-date = 2014-05-20  | archive-date = 2008-11-18  | archive-url = https://web.archive.org/web/20081118122857/http://www.microsoft.com/technet/technetmag/issues/2006/07/WindowsConfidential/ | url-status = live }}</ref>
<ref name="Brown_2002_INTER61">{{cite web |title=The x86 Interrupt List |date=2002-12-29 |author-first=Ralf D. |author-last=Brown |author-link=Ralf D. Brown |url=https://www.cs.cmu.edu/~ralf/files.html |access-date=2011-10-14 |archive-date=2016-06-16  |archive-url=https://web.archive.org/web/20160616113421/https://www.cs.cmu.edu/~ralf/files.html |url-status=live }}</ref>
<ref name="SCP_1981_86-DOS_1.0_Addendum">{{cite web|url=http://bitsavers.informatik.uni-stuttgart.de/pdf/seattleComputer/86-DOS_1.0_Addendum.pdf|title=SCP 86-DOS 1.0 Addendum|author=Seattle Computer Products|year=1981|access-date=2013-03-10|archive-date=2012-10-03 |archive-url=https://web.archive.org/web/20121003100657/http://bitsavers.informatik.uni-stuttgart.de/pdf/seattleComputer/86-DOS_1.0_Addendum.pdf|url-status=live}}</ref>
<ref name="DC-009-2010">{{cite web|url=http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-009-2010_E.pdf|title=Standard of the Camera & Imaging Products Association, CIPA DC-009-Translation-2010, Design rule for Camera File system: DCF Version 2.0 (Edition 2010)|author=JEIDA/JEITA/CIPA|year=2010|access-date=2011-04-13|url-status=dead|archive-url=https://web.archive.org/web/20130930190707/http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-009-2010_E.pdf|archive-date=2013-09-30}}</ref>
<ref name="_1992_LFNs">{{cite web|title=Getting longer filenames out of GEMDOS|url=https://groups.google.com/forum/?_escaped_fragment_=topic/comp.sys.atari.st.tech/ADwk_y6-nYg#!topic/comp.sys.atari.st.tech/ADwk_y6-nYg|author=Natuerlich!|publisher=comp.sys.atari.st.tech|date=1992-03-24|access-date=2014-05-05|archive-date=2014-04-24 |archive-url=https://web.archive.org/web/20140424004045/https://groups.google.com/forum/?_escaped_fragment_=topic%2Fcomp.sys.atari.st.tech%2FADwk_y6-nYg#!topic/comp.sys.atari.st.tech/ADwk_y6-nYg|url-status=live}}</ref>
<ref name="Torvalds_1992_LFNs">{{cite web|title=Long filenames|url=https://groups.google.com/forum/?_escaped_fragment_=topic/comp.os.minix/0rgZpprg_Eo#!topic/comp.os.minix/0rgZpprg_Eo|first=Linus|last=Torvalds|author-link=Linus Torvalds|publisher=comp.os.minix|date=1992-12-23|access-date=2014-05-05|archive-date=2014-04-23 |archive-url=https://web.archive.org/web/20140423022431/https://groups.google.com/forum/?_escaped_fragment_=topic%2Fcomp.os.minix%2F0rgZpprg_Eo#!topic/comp.os.minix/0rgZpprg_Eo|url-status=live}}</ref>
<ref name="Bell_1990_SuperFAT">{{cite journal|author1=Les Bell|author2=Associates Pty Ltd|title=OS/2 High Performance File System|journal=PC Support Advisor|orig-year=1990|date=1996-09-02|access-date=2014-06-24|url=http://www.lesbell.com.au/hpfstest.html|archive-url=https://web.archive.org/web/20140301101837/http://www.lesbell.com.au/hpfstest.html|archive-date=1 March 2014|url-status=dead}}</ref>
<ref name="Bridges_1996_SuperFAT">{{cite journal|first=Dan|last=Bridges|title=Inside the High Performance File System - Part 2/6: Introduction|journal=Significant Bits, Brisbug PC User Group Inc.|url=http://www.edm2.com/0411/hpfs2.html|date=February 1996|access-date=2014-06-24|archive-date=2015-09-23 |archive-url=https://web.archive.org/web/20150923233713/http://www.edm2.com/0411/hpfs2.html|url-status=live}}</ref>
<ref name="Haaf_1987_TOS">{{cite magazine |title=Daten auf Scheiben – File- und Diskettenstrukturen unter CP/M, MSDOS und TOS: Dateiverwaltung unter TOS |language=de |series=c't Kartei |author-first1=Wilfried |author-last1=Haaf |author-first2=Frank |author-last2=Middel |date=November 1987 |magazine=[[c't - magazin für computertechnik]] |publisher=[[Verlag Heinz Heise GmbH & Co. KG]] |volume=1987 |issue=11 |issn=0724-8679 |pages=241–246 [246]}}</ref>
}}

== External links ==
* [http://www.ecma-international.org/publications/standards/Ecma-107.htm ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange], identical to ISO/IEC 9293.
* [https://msdn.microsoft.com/en-us/windows/hardware/gg463080.aspx Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format]
* [http://www.pjrc.com/tech/8051/ide/fat32.html Understanding FAT32 file systems (explained for embedded firmware developers)]
* [https://web.archive.org/web/20131220004435/http://users.iafrica.com/c/cq/cquirke/fat.htm Understanding FAT] including lots of info about LFNs
* [http://support.microsoft.com/kb/140418/ Detailed Explanation of FAT Boot Sector]: Microsoft Knowledge Base Article 140418
* [http://support.microsoft.com/kb/154997/ Description of the FAT32 File System]: Microsoft Knowledge Base Article 154997
* [http://sourceforge.net/projects/libfat/ FAT12/FAT16/FAT32 file system implementation for *nix]: Includes libfat libraries and fusefat, a FUSE file system driver
* [http://support.microsoft.com/kb/39927/ MS-DOS: Directory and Subdirectory Limitations]: Microsoft Knowledge Base Article 39927
* [http://support.microsoft.com/kb/100108/ Overview of FAT, HPFS, and NTFS File Systems]: Microsoft Knowledge Base Article 100108
* [https://web.archive.org/web/20060307082555/http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c13621675.mspx ''Volume and file size limits of FAT file systems'']: Microsoft Technet, copy made by [https://archive.org/ Internet Archive Wayback Machine] 
* [https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc160978(v=msdn.10) Microsoft TechNet: A Brief and Incomplete History of FAT32] by [[Raymond Chen (Microsoft)|Raymond Chen]]
* [http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm FAT32 Formatter] {{Webarchive|url=https://web.archive.org/web/20090721075507/http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm |date=2009-07-21  }}: allows formatting volumes larger than {{nowrap|32 GB}} with FAT32 under [[Windows 2000]], [[Windows XP]] and [[Windows Vista]]
* [https://web.archive.org/web/20170610205053/https://support.microsoft.com/en-us/help/263044/fdisk-does-not-recognize-full-size-of-hard-disks-larger-than-64-gb Fdisk does not recognize full size of hard disks larger than {{nowrap|64 GB}}]: Microsoft Knowledge Base Article 263044, copy made by [https://archive.org/web/ Internet Archive Wayback Machine].  Explains inability to work with extremely large volumes under Windows 95/98.
* [https://web.archive.org/web/20050319235548/http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_cycz.asp Microsoft Windows XP: FAT32 File System]. Copy made by [https://archive.org/ Internet Archive Wayback Machine] of an article with summary of limits in FAT32 which is no longer available on Microsoft website.
* [https://web.archive.org/web/20140528122441/http://www.beginningtoseethelight.org/fat16/ Visual Layout of a FAT16 drive]

{{File systems}}
{{Microsoft Windows components}}
{{Ecma International Standards}}
{{ISO standards}}

<!-- Contents split from chapter "Technical design" of main article [[File Allocation Table]], oldid=609099290 on 2014-05-20. -->

<!-- [[Category:1977 software]] Not enabled since we don't discuss 8-bit/10-bit FATs inhere, but in [[File Allocation Table]].  -->
[[Category:1980 software]]<!-- FAT12 was introduced in 1980 -->
[[Category:Computer file systems]]
[[Category:Disk file systems]]
[[Category:DOS technology]]
[[Category:Windows components]]
[[Category:Windows disk file systems]]
[[Category:Ecma standards]]
[[Category:File systems supported by the Linux kernel]]

[[fr:File Allocation Table#Aspect technique]]
{{Навигационная таблица/Портал/Английская Википедия}}
[[Категория:Английская Википедия]]
[[Категория:Википедия]]
[[Категория:Статья из Википедии]]
[[Категория:Статья из Английской Википедии]]