File Allocation Table: Difference between revisions
m I think there should be a wp:hyphen |
|||
Line 75: | Line 75: | ||
== Historical evolution == |
== Historical evolution == |
||
{{Main|File Allocation table historical evolution}} |
|||
{{split section|discuss=Talk:File_Allocation_Table#What_is_this_huge_thing_in_the_middle.3F|date=February 2014}} |
|||
{{See also|Timeline of DOS operating systems}} |
{{See also|Timeline of DOS operating systems}} |
||
The FAT file system was first implemented in the 1970s by Microsoft. Since then it has undergone significant evolution in support of increased storage capacity and functionality. Different variants and versions of the file system were introduced along the way. Different versions are not necessarily implemented by Microsoft nor are they necessarily compatible with one another. |
|||
=== File system types{{anchor|Types}} === |
|||
==== Original 8-bit FAT{{anchor|FAT8|FAT10}} ==== |
|||
<!-- NB. "FAT8" and "FAT10" are used as handy invisible anchors, but they never were the official names for these FAT variants, and therefore must not be used in the visible text. --> |
|||
The original FAT file system (or ''FAT structure'', as it was called initially) was designed and coded by [[Marc McDonald]],<ref name="Duncan_1988_MS-DOS_Encyclopedia"/> based on a series of discussions between McDonald and [[Bill Gates]].<ref name="Duncan_1988_MS-DOS_Encyclopedia"/><!-- some sources state 1977, others 1976, some even attribute the invention to Gates during a hotel stay in Albuquerque --> |
|||
It was introduced with [[8-bit]] table elements<ref name="Duncan_1988_MS-DOS_Encyclopedia"/> (and valid data cluster numbers <!-- <tt>0x02</tt>TBD: 0x02 according to McDonald, but 0x00 according to original documentation --> up to <tt>0xBF</tt><!-- according to McDonald -->) in [[Microsoft]]'s ''[[Standalone Disk BASIC-80]]'' for a [[Intel 8080|8080]]-based successor<ref group="nb" name="NB_NCR_FAT"/> of the [[NCR Corporation|NCR]] 7200 data-entry terminal with 8-inch (200 mm) floppy disks in 1977.<ref name="Manes_1993_Gates"/> |
|||
In 1978,<!-- other sources state 1979 --> ''Standalone Disk BASIC-80'' was ported to the [[Intel 8086|8086]] using an emulator on a DEC [[PDP-10]],<ref name="Hunter_1983_Softalk"/> since no real 8086 systems were available at this time. |
|||
The FAT file system was also utilized in Microsoft's [[MIDAS (operating system)|MDOS/MIDAS]],<ref name="Duncan_1988_MS-DOS_Encyclopedia"/> an operating system for 8080/Z80 platforms written by McDonald since 1979. |
|||
The ''Standalone Disk BASIC'' version supported three FATs,<ref name="Schulman_1994_Undocumented-DOS"/> whereas this was a <!-- compile time? -->parameter for MIDAS.<!-- according to Marc McDonald --> Reportedly, MIDAS was also prepared to support 10-bit, 12-bit and 16-bit FAT variants.<!-- according to Marc McDonald --> |
|||
While the size of directory entries was 16 bytes in ''Standalone Disk BASIC'', MIDAS instead occupied 32 bytes per entry.<!-- according to Marc McDonald, but probably not identical to the 32 byte entries in the later QDOS FAT12 layout --> |
|||
[[Tim Paterson]] of [[Seattle Computer Products]] (SCP) was first introduced to Microsoft's FAT structure when he helped [[Bob O'Rear]] adapting the ''[[Standalone Disk BASIC-86]]'' emulator port onto SCP's [[S-100 bus]] 8086 CPU board prototype during a guest week at Microsoft in May 1979.<ref name="Hunter_1983_Softalk"/> The final product was shown at [[Lifeboat Associates]]' booth stand at the [[National Computer Conference]] in New York<ref name="Hunter_1983_Softalk"/> on 4–7 June 1979, where Paterson learned about the more sophisticated FAT implementation in MDOS/MIDAS<ref name="Duncan_1988_MS-DOS_Encyclopedia"/> and McDonald talked to him about the design of the file system.<ref name="Manes_1993_Gates"/> |
|||
==== FAT12 ==== |
|||
<!-- NB. The header "FAT12" is used in redirects to this page. --> |
|||
Between April and August 1980,<!-- work on QDOS began in April and 0.10 was reached in July --> while borrowing the FAT concept for SCP's own 8086 operating system [[QDOS 0.10]],<ref name="Hunter_1983_Softalk"/> Tim Paterson extended the table elements to 12 bits,<ref name="Paterson_2007_Design-DOS"/> reduced the number of FATs to two, redefined the semantics of some of the reserved cluster values<!-- according to Marc McDonald in 2012-08 -->, and modified the disk layout, so that the root directory was now located between the FAT and the data area<!-- according to Marc McDonald in 2012-08 --> for his implementation of '''FAT12'''. Paterson also increased the nine-character (6.3) filename length limit to eleven characters in order to support [[CP/M]]-style [[8.3 filename]]s and [[File Control Block]]s. The format used in Microsoft ''Standalone Disk BASIC's'' 8-bit file system precursor was not supported by QDOS. By August 1980, QDOS<!-- either for 0.2 or immediately afterwards --> had been renamed into [[86-DOS]]<!-- 0.3 --> already.<ref name="BYTE_1980_86-DOS"/> Starting with [[86-DOS 0.42]], the size and layout of directory entries was changed from 16 bytes to 32 bytes<ref name="SCP_1981_86-DOS_1.0_Addendum"/><!-- and according to Marc McDonald in 2012-08 --> in order to add a file date stamp<ref name="SCP_1981_86-DOS_1.0_Addendum"/> and increase the theoretical file size limit beyond the previous limit of 16 MiB.<ref name="SCP_1981_86-DOS_1.0_Addendum"/> |
|||
[[86-DOS 1.00]] became available in early 1981. Later in 1981, 86-DOS evolved into Microsoft's [[MS-DOS]] and [[IBM]] [[PC DOS]].<ref name="Duncan_1988_MS-DOS_Encyclopedia"/><ref name="Paterson_2007_Design-DOS"/><ref name="Wallace_1992_Harddrive"/> |
|||
The capability to read previously formatted volumes with 16-byte directory entries<ref name="SCP_1981_86-DOS_1.0_Addendum"/> was dropped with [[MS-DOS 1.20]].<!-- and PC DOS 1.1, so the last known version known to support it is MS-DOS 1.14. Not sure about PC DOS 1.0. --> |
|||
Originally designed as a file system for floppy disks, FAT12 used 12-bit entries for the cluster addresses in the FAT, which not only limited the maximum generally possible count of data clusters to 4078 (for data clusters <tt>0x002</tt> to <tt>0xFEF</tt>)<ref name="Norton2"/><ref name="Jenkinson_2000_Forensic"/> or in some controlled scenarios even up to 4084 (for data clusters <tt>0x002</tt> to <tt>0xFF5</tt>),<ref name="Ecma-107"/><ref name="efi"/><ref name="max4084"/> but made FAT manipulation tricky with the PC's [[8-bit]] and [[16-bit]] registers. (While MS-DOS and PC DOS support up to 4084 data clusters on FAT12 volumes in general, cluster value <tt>0xFF0</tt><ref group="nb" name="NB_MAGIC_FF0"/> is treated as additional end-of-chain marker on any FAT12 volume<ref name="Chappell_1994_DOS-Internals"/> since [[MS-DOS 3.3|MS-DOS]]/[[PC DOS 3.3]], which also introduced the <tt>0xF0</tt> [[#media|media descriptor]] value, therefore restricting the maximum practical number of data clusters to 4078 for compatibility purposes with these operating systems.) |
|||
The disk's size was stored and calculated as a 16-bit count of [[Cylinder-head-sector|sectors]], which limited the size to 32 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> for a logical sector size of 512 bytes. FAT12 was used by several manufacturers with different physical formats, but a typical floppy disk at the time was 5.25-inch (130 mm), single-sided, 40 [[Cylinder-head-sector|tracks]], with 8 sectors per track, resulting in a capacity of 160 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> for both the system areas and files. The FAT12 limitations exceeded this capacity by a factor of ten or more. (NB. The 32 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> limit was later circumvented using [[#Logical sectored FAT|logical sectored FAT]]s with logical sector sizes larger than 512 bytes in some OEM versions of MS-DOS 3.x, but this fell into disuse when [[#FAT16B|FAT16B]] became available with DOS 3.31, which supported [[32-bit]] sector numbers and thereby further lifted the limits.) |
|||
By convention, all the control structures were organized to fit inside the first track, thus avoiding head movement during read and write operations, although this varied depending on the manufacturer and physical format of the disk. A limitation which was not addressed until much later (with [[#FAT32|FAT32]]) was that any bad sector in the control structures area, track 0, could prevent the disk from being usable. The DOS formatting tool rejected such disks completely. Bad sectors were allowed only in the file data area and (since DOS 2.0) were marked with the reserved value <tt>0xFF7</tt> in the FAT. They made the entire containing cluster unusable. |
|||
While 86-DOS supported three disk formats (250.25 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr>, 616 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> and 1232 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> with [[#FATID|FAT ID]]s <tt>0xFF</tt> and <tt>0xFE</tt><!-- it's not clear if QDOS/86-DOS already used the FAT ID byte, or if this was added with MS-DOS/PC DOS 1.x. Definitely known: Standalone Disk BASIC and MIDAS did not support the FAT ID byte. Also, sources differ in regard to the actual format assignment for the 0xFF, 0xFE and 0xFD IDs. Details to be sorted out. -->) on 8-inch (200 mm) floppy drives, IBM [[PC DOS 1.0]], released with the original [[IBM Personal Computer]] in 1981, supported only an 8-sector floppy format with a formatted capacity of 160 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> (FAT ID <tt>0xFE</tt>) for single-sided 5.25-inch floppy drives, and [[PC DOS 1.1]] added support for a [[double-sided disk|double-sided]] format with 320 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> (FAT ID <tt>0xFF</tt>). [[PC DOS 2.0]] introduced support for 9-sector floppy formats with 180 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> (FAT ID <tt>0xFC</tt>) and 360 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> (FAT ID <tt>0xFD</tt>). |
|||
86-DOS 1.00 and PC DOS 1.0 directory entries included only one date, the last modified date. PC DOS 1.1 added the last modified time. PC DOS 1.x [[file attribute]]s included a hidden bit and system bit, with the remaining six bits undefined. At this time, DOS did not support a hierarchical file system, which was still acceptable, given that the number of files on a disk was typically not more than a few dozen. |
|||
The [[PC XT]] was the first PC with a hard drive from IBM, and PC DOS 2.0 supported that hard drive with FAT12 ([[#FATID|FAT ID]] <tt>0xF8</tt>). The fixed assumption of 8 sectors per clusters on hard disks practically limited the maximum partition size to 16 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> for 512 byte sectors and 4 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> clusters. |
|||
The ''[[BIOS Parameter Block]]'' (''BPB'') was introduced with PC DOS 2.0 as well, and this version also added read-only, [[archive bit|archive]], [[volume (computing)|volume label]], and [[Directory (file systems)|directory]] attribute bits for hierarchical sub-directories.<ref name="two"/> |
|||
[[MS-DOS 3.0]] introduced support for high-density 1.2 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> 5.25-inch diskettes (media descriptor <tt>0xF9</tt>), which notably had 15 sectors per track, hence more space for the FATs. |
|||
FAT12 remains in use on all common [[floppy disks]], including 1.44 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> and later 2.88 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> disks (media descriptor byte <tt>0xF0</tt>). |
|||
==== Initial FAT16{{anchor|FAT16}} ==== |
|||
On 14 August 1984, IBM released the [[PC AT]], which featured a 20 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> hard disk and PC DOS 3.0.<ref name="IBM_1984_PCDOS30"/><ref name="IBM_1985_Reference"/> Microsoft introduced MS-DOS 3.0 in parallel. Cluster addresses were increased to 16-bit, allowing for up to 65,524 clusters per volume, and consequently much greater file system sizes, at least in theory. However, the maximum possible number of sectors and the maximum ([[Disk partitioning|partition]], rather than disk) size of 32 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> did not change. Therefore, although cluster addresses were 16 bits, this format was not what today is commonly understood as '''FAT16'''. |
|||
A [[partition type]] <tt>[[Partition type#PID_04h|0x04]]</tt> indicates this form of FAT16 with less than 65536 sectors (less than 32 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> for sector size 512). |
|||
With the initial implementation of FAT16 not actually providing for larger partition sizes than FAT12, the early benefit of FAT16 was to enable the use of smaller clusters, making disk usage more efficient, particularly for large numbers of files only a few hundred bytes in size, which were far more common at the time. |
|||
MS-DOS 2.x hard disks larger than 15 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> are incompatible with later versions of MS-DOS.<ref name="Microsoft_69912"/> A 20 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> hard disk formatted under MS-DOS 3.0 was not accessible by the older MS-DOS 2.0 because MS-DOS 2.0 did not support version 3.0's FAT16. MS-DOS 3.0 could still access MS-DOS 2.0 style 8 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr>-cluster partitions under 15 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr>. |
|||
==== Logical sectored FAT ==== |
|||
<!-- NB. The header "Logical sectored FAT" is used in redirects to this page. --> |
|||
When hard disks grew larger and the FAT12 and FAT16 file system implementation in MS-DOS / PC DOS did not provide means to take advantage of the extra storage, several manufacturers developed their own FAT variants to address the problem in their MS-DOS OEM issues. |
|||
Some vendors ([[AST Research|AST]] and [[NEC]]) supported eight, instead of the standard four, primary partition entries in their custom extended ''[[Master Boot Record]]'' (''MBR''), and they adapted MS-DOS to use more than a single primary partition. |
|||
Other vendors worked around the volume size limits imposed by the 16-bit sector entries and arithmetics by increasing the ''size'' of the sectors the file system dealt with, thereby blowing up dimensions. |
|||
These so-called ''logical sectors'' were larger (up to 8192 bytes) than the ''physical sector'' size (still typically 512 bytes) as expected by the [[ROM-BIOS]] [[INT 13H|INT 13h]]<!-- not sure if these OEM versions supported INT 13h, as the classical INT 13h is bound to 512 bytes. --> or the disk drive hardware. The DOS-BIOS or System BIOS would then combine multiple physical sectors into logical sectors for the file system to work with. |
|||
These changes were transparent to the file system implementation in the DOS kernel, since on the file system's abstraction level volumes are seen as a linear series of logically addressable sectors, also known as ''absolute sectors'' (addressed by their ''Logical Sector Number'' (''LSN''), starting with LSN 0)<!-- similar to what much later and on a lower level, became known as LBA, though not directly related --> independent of the physical location of the volume on the physical medium and its geometry. The underlying DOS-BIOS translated these logical sectors into physical sectors according to partitioning information and the drive's physical geometry. |
|||
The drawback of this approach was a less memory-efficient sector buffering and deblocking in the DOS-BIOS, thereby causing an increased memory footprint for the DOS data structures. |
|||
Since older DOS versions were not flexible enough to work with these logical geometries, the OEMs had to introduce new partition IDs for their FAT variants in order to hide them from off-the-shelf issues of MS-DOS and PC DOS. Known partition IDs for logical sectored FATs include: <tt>[[Partition type#PID_08h|0x08]]</tt> ([[Commodore International|Commodore]] MS-DOS 3.x), <tt>[[Partition type#PID_11h|0x11]]</tt> ([[Leading Edge Hardware Products|Leading Edge]] MS-DOS 3.x), <tt>[[Partition type#PID_14h|0x14]]</tt> (AST MS-DOS 3.x), <tt>[[Partition type#PID_24h|0x24]]</tt> (NEC MS-DOS 3.30), <tt>[[Partition type#PID_56h|0x56]]</tt> ([[AT&T Corporation|AT&T]] MS-DOS 3.x), <tt>[[Partition type#PID_E5h|0xE5]]</tt> ([[Tandy Computers|Tandy]] MS-DOS), <tt>[[Partition type#PID_F2h|0xF2]]</tt> ([[Sperry Corporation|Sperry IT]] MS-DOS 3.x, [[Unisys]] MS-DOS 3.3 — also used by [[Digital Research]] [[DOS Plus]] 2.1).<ref name="Brouwer_2002_Partition-IDs"/> OEM versions like Toshiba MS-DOS, Wyse MS-DOS 3.2<!-- with 1024 bytes/sector --> and 3.3,<ref name="Microsoft_2000_Wyse-DOS"/> as well as Zenith MS-DOS are also known to have utilized logical sectoring.<ref name="Microsoft_2000_Logical-sectoring"/><!-- but partition IDs and other specifics of these formats are not known --> |
|||
While non-standard and sub-optimal, these FAT variants are perfectly valid according to the specifications of the file system itself. Therefore, even if default issues of MS-DOS and PC DOS were not able to cope with them, most of these vendor-specific FAT12 and FAT16 variants can be mounted by more flexible file system implementations in operating systems such as DR-DOS, simply by changing the partition ID to one of the recognized types.<ref group="nb" name="NB_DRDOS_Logical-Sectoring"/> Also, if they no longer need to be recognized by their original operating systems, existing partitions can be "converted" into FAT12 and FAT16 volumes more compliant with versions of MS-DOS/PC DOS 4.0-6.3, which do not support sector sizes different from 512 bytes,<ref name="Brouwer_2002_Logical_FAT"/> by switching to a [[#BPB331|BPB with 32-bit entry]] for the number of sectors, as introduced since DOS 3.31 (see [[#FAT16B|FAT16B]] below), keeping the cluster size and reducing the logical sector size in the BPB down to 512 bytes, while at the same time increasing the counts of logical sectors per cluster, reserved logical sectors, total logical sectors, and logical sectors per FAT by the same factor. |
|||
A parallel development in MS-DOS / PC DOS which allowed an increase in the maximum possible FAT size was the introduction of multiple FAT partitions on a hard disk. To allow the use of more FAT partitions in a compatible way, a new partition type was introduced in PC DOS 3.2 (1986), the ''[[Extended boot record|extended partition]]'' (EBR),<ref name="Duncan_1988_MS-DOS_Encyclopedia"/> which is a container for an additional partition called ''logical drive''. Since PC DOS 3.3 (April 1987), there is another, optional extended partition containing the next ''logical drive'', and so on. The [[Master Boot Record|MBR]] of a hard disk can either define up to four primary partitions, or an extended partition in addition to up to three primary partitions. |
|||
{{See also|Extended boot record}} |
|||
==== Final FAT16{{anchor|FAT16B|FAT16X}} ==== |
|||
Finally in November 1987, [[Compaq]] MS-DOS 3.31 (a modified OEM version of MS-DOS 3.3 released by Compaq with their machines) introduced what today is simply known as ''the FAT16'' format, with the expansion of the 16-bit disk sector count to 32 bits in the BPB. |
|||
Although the on-disk changes were minor, the entire DOS disk driver had to be converted to use 32-bit sector numbers, a task complicated by the fact that it was written in 16-bit [[x86 assembly language|assembly language]]. |
|||
The result was initially called the ''DOS 3.31 Large File System''. [[Microsoft]]'s DSKPROBE tool refers to type <tt>[[Partition type#PID_06h|0x06]]</tt> as ''BigFAT'',<ref name="Microsoft_2003_CC736327"/> whereas some older versions of FDISK described it as ''BIGDOS''. Technically, it is known as '''FAT16B'''. |
|||
Since older versions of DOS were not designed to cope with more than 65535 sectors, it was necessary to introduce a new partition type for this format in order to hide it from pre-3.31 issues of DOS. The original form of FAT16 (with less than 65536 sectors) had a [[partition type]] <tt>[[Partition type#PID_04h|0x04]]</tt>. To deal with disks larger than this, type <tt>[[Partition type#PID_06h|0x06]]</tt> was introduced to indicate 65536 or more sectors. In addition to this, the disk driver was expanded to cope with more than 65535 sectors as well. The only other difference between the original FAT16 and the newer FAT16B format is the usage of a [[#BPB331|newer BPB]] format with 32-bit sector entry. Therefore, newer operating systems supporting the FAT16B format can cope also with the original FAT16 format without any necessary changes. |
|||
If partitions to be used by pre-DOS 3.31 issues of DOS need to be created by modern tools, the only criteria theoretically necessary to meet are a sector count of less than 65536, and the usage of the old partition ID (<tt>[[Partition type#PID_04h|0x04]]</tt>). In practice however, type <tt>[[Partition type#PID_01h|0x01]]</tt> and <tt>[[Partition type#PID_04h|0x04]]</tt> primary partitions should not be physically located outside the first 32 <abbr title="mebibyte (1024 KiB or 1,048,576 bytes)">MiB</abbr> of the disk, due to other restrictions in MS-DOS 2.x, which could not cope with them otherwise. |
|||
In 1988, the FAT16B improvement became more generally available through [[DR DOS]] 3.31, PC DOS 4.0, [[OS/2]] 1.1, and MS-DOS 4.0. The limit on partition size was dictated by the 8-bit [[Signedness|signed]] count of sectors per cluster, which originally had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> cluster size, thereby fixing the "definitive" limit for the FAT16 partition size at 2 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr> for sector size 512. On [[magneto-optical]] media, which can have 1 or 2 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> sectors instead of 0.5 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr>, this size limit is proportionally larger. |
|||
Much later, [[Windows NT]] increased the maximum cluster size to 64 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr>, by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater [[internal fragmentation]]. [[Windows 98]], SE and ME also supported reading and writing this variant, but its disk utilities did not work with it and some [[File control block|FCB]] services are not available for such volumes. This contributes to a confusing compatibility situation. |
|||
Prior to 1995, versions of DOS accessed the disk via [[Cylinder-head-sector|CHS]] addressing only. When MS-DOS 7.0 / [[Windows 95]] introduced [[Logical block addressing|LBA]] disk access, partitions could start being physically located outside the first ca. 8 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr><!-- exact value is somewhat smaller --> of this disk and thereby out of the reach of the traditional CHS addressing scheme. Partitions partially or fully located beyond the CHS barrier therefore had to be hidden from non-LBA-enabled operating systems by using the new partition type <tt>[[Partition type#PID_0Eh|0x0E]]</tt> in the partition table instead. FAT16 partitions using this partition type are also named '''FAT16X'''.<ref name="Microsoft_2004_KB120138"/> The only difference, compared to previous FAT16 partitions, is the fact that some CHS-related geometry entries in the BPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used. |
|||
The number of root directory entries available for FAT12 and FAT16 is determined when the volume is formatted, and is stored in a 16-bit field. For a given number <code>RDE</code> and sector size <code>SS</code>, the number <code>RDS</code> of root directory sectors is <code>RDS=ceil((RDE×32)/SS)</code>, and <code>RDE</code> is normally chosen to fill these sectors, i.e., <code>RDE*32=RDS*SS</code>. FAT12 and FAT16 media typically use 512 root directory entries on non-floppy media. Some third-party tools, like [[mkdosfs]], allow the user to set this parameter.<ref name="MKDOSFS"/> |
|||
==== FAT32{{anchor|FAT32X|FAT+}} ==== |
|||
<!-- NB. The header "FAT32" and the anchors "FAT32X" and "FAT+" are used in redirects to this page. --> |
|||
In order to overcome the volume size limit of FAT16, while at the same time allowing DOS [[real mode]] code to handle the format, Microsoft designed a new version of the file system, '''FAT32''', which supported an increased number of possible clusters, but could reuse most of the existing code, so that the available [[conventional memory]] footprint was reduced by less than 5 KiB under DOS.<ref name="Microsoft_1998_CC768180"/> Cluster values are represented by [[32-bit]] numbers, of which 28 bits are used to hold the cluster number. The boot sector uses a 32-bit field for the sector count, limiting the FAT32 volume size to 2 <abbr title="tebibyte (1024 GiB or 1,048,576 MiB or 1,073,741,824 KiB or 1,099,511,627,776 bytes)">TiB</abbr> for a sector size of 512 bytes and 16 <abbr title="tebibyte (1024 GiB or 1,048,576 MiB or 1,073,741,824 KiB or 1,099,511,627,776 bytes)">TiB</abbr> for a sector size of 4,096 bytes.<ref name="Microsoft_2007_KB184006"/><ref name="Microsoft_2007_KB314463"/> |
|||
FAT32 was introduced with MS-DOS 7.1 / Windows 95 OSR2 in 1996, although reformatting was needed to use it, and [[DoubleSpace#DriveSpace in Windows 95|DriveSpace 3]] (the version that came with Windows 95 OSR2 and Windows 98<!-- what about ME? -->) never supported it. Windows 98 introduced a utility to convert existing hard disks from FAT16 to FAT32 without loss of data. |
|||
In the Windows NT line, native support for FAT32 arrived in [[Windows 2000]]. A free FAT32 driver for [[Windows NT 4.0]] was available from [[Winternals]], a company later acquired by Microsoft. Since the acquisition the driver is no longer officially available. |
|||
Since 1998, Caldera's dynamically loadable [[DRFAT32]] driver could be used to enable FAT32 support in DR-DOS. The first version of DR-DOS to natively support FAT32 and LBA access was OEM DR-DOS 7.04 in 1999. That same year [[Intelligent Micro Software|IMS]] introduced native FAT32 support with [[REAL/32]] 7.90, and [[IBM 4690 OS]] added FAT32 support with version 2.<ref name="IBM_4690_User_Guide"/> [[Ahead Software]] provided another dynamically loadable FAT32.EXE driver for DR-DOS 7.03 with [[Nero Burning ROM]] in 2004.<!-- with copyrights 2002-2004 --> IBM PC DOS introduced native FAT32 support with OEM PC DOS 7.10 in 2003. |
|||
The maximum possible size for a file on a FAT32 volume is 4 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr> minus 1 byte or 4,294,967,295 (2<sup>32</sup> − 1) bytes. This limit is a consequence of the file length entry in the directory table and would also affect huge FAT16 partitions with a sufficient sector size.<ref name="GB4"/> Video applications, DVD images, large databases, and some other software easily exceed this limit. |
|||
The open FAT+<ref name="DRDOS_FAT+_R2"/> specification proposes how to store [[Large file support|larger files]] up to 256 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr> minus 1 byte or 274,877,906,943 (2<sup>38</sup> − 1) bytes on slightly modified and otherwise backwards compatible FAT32 volumes, but imposes a risk that disk tools or FAT32 implementations not aware of this extension may truncate or delete files exceeding the normal FAT32 file size limit. Also, support for '''FAT32+''' (and '''FAT16+''') is limited to some versions of [[DR-DOS]] and not available in mainstream operating systems so far. (This extension is critically incompatible with the <code>/EAS</code> option of the FAT32.IFS method to store [[#EA|OS/2 extended attributes]] on FAT32 volumes.) |
|||
As with previous file systems, the design of the FAT32 file system does not include direct built-in support for long filenames, but FAT32 volumes can optionally hold [[#VFAT|VFAT]] long filenames in addition to short filenames in exactly the same way as VFAT long filenames have been optionally implemented for FAT12 and FAT16 volumes. |
|||
Two partition types have been reserved for FAT32 partitions, <tt>[[Partition type#PID_0Bh|0x0B]]</tt> and <tt>[[Partition type#PID_0Ch|0x0C]]</tt>. The latter type is also named '''FAT32X''' in order to indicate usage of LBA disk access instead of CHS. On such partitions, some CHS-related geometry entries in the EBPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used. |
|||
=== Extensions === |
|||
<!-- ==== Flash and ROM FAT extensions ==== for FAT extensions like FTL |
|||
==== Secured FAT ==== for single/multiuser security schemes including those by DRI and Linux |
|||
==== Compressed FAT ==== for compressed and encrypted FAT schemes |
|||
==== Deletion tracking ==== for MSX-DOS, SAVENAME, DELWATCH, SENTRY, UNDELETE, RECYCLE etc. |
|||
==== Large file support ==== for files larger than 2/4 GiB, FAT+ etc. |
|||
==== Transaction-safe FAT ==== for TFAT and other transaction safe FAT variants --> |
|||
==== {{anchor|EA}}Extended Attributes ==== |
|||
[[OS/2]] heavily depends on [[extended attribute]]s (EAs) and stores them in a hidden file called "<code>EA␠DATA.␠SF</code>"<!-- Since the exact spelling is important and most sources list only 10 of the 8+3 available characters in directory entries, recheck the exact 8+3 byte spelling of this filename --> in the [[root directory]] of the [[#FAT12|FAT12]] or [[#FAT16|FAT16]] volume. This file is indexed by two previously reserved bytes in the file's (or directory's) [[#DIR|directory entry]] at offset [[#DIR_OFS_14h|<tt>0x14</tt>]].<ref name="Eager_2000_EA"/> In the [[#FAT32|FAT32]] format, these bytes hold the upper 16 bits of the starting cluster number of the file or directory, hence making it impossible to store [[OS/2 EA]]s on FAT32 using this method. |
|||
However, the third-party FAT32 [[installable file system]] (IFS) driver FAT32.IFS version 0.70 and higher by Henk Kelder & Netlabs for OS/2 and [[eComStation]] stores extended attributes in extra files with filenames having the string "<code>␠EA.␠SF</code>" appended to the regular filename of the file to which they belong. The driver also utilizes the byte at offset [[#DIR_OFS_0Ch|<tt>0x0C</tt>]] in directory entries to store a special mark byte indicating the presence of extended attributes to help speed up things.<ref name="Kelder_2003_FAT32IFS0913"/><ref name="Kelder_FAT32IFS074"/> (This extension is critically incompatible with the FAT32+ method to store files larger than 4 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr> minus 1 on FAT32 volumes.<ref name="DRDOS_FAT+_R2"/>) |
|||
Extended attributes are accessible via the [[Workplace Shell]] desktop, through [[REXX]] scripts, and many system [[graphical user interface|GUI]] and [[command line interface|command-line]] utilities (such as [[4OS2]]).<ref name="Eager_2000_Tavi"/> |
|||
To accommodate its [[OS/2]] subsystem, [[Windows NT]] supports the handling of extended attributes in [[High Performance File System|HPFS]], [[NTFS]], FAT12 and FAT16. It stores EAs on FAT12, FAT16 and HPFS using exactly the same scheme as OS/2, but does not support any other kind of [[Alternate Data Streams|ADS]] as held on NTFS volumes. Trying to copy a file with any ADS other than EAs from an NTFS volume to a FAT or HPFS volume gives a warning message with the names of the ADSs that will be lost. It does not support the FAT32.IFS method to store EAs on FAT32 volumes. |
|||
[[Windows 2000]] onward acts exactly as Windows NT, except that it ignores EAs when copying to FAT32 without any warning (but shows the warning for other ADSs, like "Macintosh Finder Info" and "Macintosh Resource Fork"). |
|||
[[Cygwin]] uses "<code>EA␠DATA.␠SF</code>" files as well. |
|||
==== {{anchor|VFAT|UVFAT}}Long file names ==== |
|||
One of the [[user experience]] goals for the designers of [[Windows 95]] was the ability to use [[long filename]]s (LFNs—up to 255 [[UCS-2]] [[code unit]]s long), in addition to classic [[8.3 filename]]s (SFNs). For [[backward compatibility|backward]] and [[forward compatibility]] LFNs were implemented as an optional extension on top of the existing FAT file system structures using a [[workaround]] in the way directory entries are laid out. |
|||
This transparent method to store long file names in the existing FAT file systems without altering their data structures is usually known as '''[[#VFAT long file names|VFAT]]''' (for "Virtual FAT") after the Windows 95 [[VxD|virtual device driver]].<ref group="nb" name="NB_VFAT_Name"/> |
|||
Non VFAT-enabled operating systems can still access the files under their short file name alias without restrictions, however, the associated long file names may get lost, when files with long file names are copied under non VFAT-aware operating systems. |
|||
In Windows NT, support for VFAT long filenames started from version [[Windows NT 3.5|3.5]]. |
|||
Linux provides a VFAT filesystem driver to work with FAT volumes with VFAT long filenames. For some while, a [[UVFAT]] driver was available to provide combined support for [[#UMSDOS|UMSDOS]]-style permissions with VFAT long filenames. |
|||
[[OS/2]] added long filename support to FAT using [[#EA|extended attributes]] (EA) before the introduction of VFAT; thus, VFAT long filenames are invisible to OS/2, and EA long filenames are invisible to Windows, therefore experienced users of both operating systems would have to manually rename the files. |
|||
In order to support [[Java (programming language)|Java]] applications, the [[FlexOS]]-based [[IBM 4690 OS]] version 2 introduced its own [[virtual file system]] (VFS) architecture to store long filenames in the FAT file system in a backwards compatible fashion. If enabled, the virtual filenames (VFN) are available under separate logical drive letters, whereas the real filenames (RFN) remain available under the original drive letters.<ref name="IBM_4690_Programming_Guide"/> |
|||
==== {{anchor|ADS}}Forks and Alternate Data Streams ==== |
|||
The FAT file system itself is not designed for supporting [[Alternate Data Streams]] ([[Fork (filesystem)|ADS]]), but some operating systems that heavily depend on them have devised various methods for handling them in FAT drives. Such methods either store the additional information in extra files and directories ([[Mac OS]]), or give new semantics to previously unused fields of the FAT on-disk data structures ([[OS/2]] and [[Windows NT]]). |
|||
Mac OS using [[PC Exchange]] stores its various dates, file attributes and long filenames in a [[hidden file]] called "<code>FINDER.DAT</code>", and [[resource fork]]s (a common Mac OS ADS) in a subdirectory called "<code>RESOURCE.FRK</code>", in every directory where they are used. From PC Exchange 2.1 onwards, they store the Mac OS long filenames as standard FAT long filenames and convert FAT filenames longer than 31 characters to unique 31-character filenames, which can then be made visible to Macintosh applications. |
|||
[[Mac OS X]] stores resource forks and metadata (file attributes, other ADS) in a hidden file with a name constructed from the owner filename prefixed with "<code>._</code>", and Finder stores some folder and file metadata in a hidden file called "<code>.DS_Store</code>". |
|||
==== {{anchor|UMSDOS}}UMSDOS permissions and filenames ==== |
|||
{{further2|[[FAT filesystem and Linux]]}} |
|||
Early Linux distributions also supported a format known as [[UMSDOS]], a FAT variant with Unix file attributes (such as long file name and access permissions) stored in a separate file called "<code>--linux-.---</code>". UMSDOS fell into disuse after [[#VFAT|VFAT]] was released and it is not enabled by default in [[Linux kernel]]s from version 2.5.7 onwards.<ref name="Linux_ChangeLog257"/> For some time, Linux also provided combined support for UMSDOS-style permissions and VFAT long filenames through [[UVFAT]]. |
|||
=== Derivatives === |
|||
==== Turbo FAT ==== |
|||
{{Main|Turbo FAT}} |
|||
In its [[NetWare File System]] ([[NWFS]]) [[Novell]] implemented a heavily modified variant of a FAT file system for the [[NetWare]] operating system. For larger files it utilized a performance feature named [[Turbo FAT]]. |
|||
==== FATX ==== |
|||
<!-- NB. The header "FATX" is used in redirects to this page. --> |
|||
<!-- {{Main|FATX}} should be created instead of further expanding this FATX section --> |
|||
FATX is a family of file systems designed for [[Microsoft]]'s [[Xbox (console)|Xbox]] [[video game console]] [[hard disk]] drives and [[memory card]]s,<ref name="Xbox_FATX-Spec"/><ref name="Xbox_Linux"/> introduced in 2001. |
|||
While resembling the same basic design ideas as [[#FAT16|FAT16]] and [[#FAT32|FAT32]], the '''FATX16''' and '''FATX32''' on-disk structures are simplified but fundamentally incompatible with normal FAT16 and FAT32 file systems, making it impossible for normal FAT file system drivers to mount such volumes. |
|||
The non-bootable [[superblock (file systems)|superblock]] sector is 4 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> in size and holds an 18 byte large BPB-like structure completely different from normal [[#BPB|BPB]]s. Clusters are typically 16 <abbr title="kibibyte (1024 or 2×512 bytes)">KiB</abbr> in size and there is only one copy of the FAT on the Xbox. Directory entries are 64 bytes in size instead of the normal [[#DIR|32 bytes]]. Files can have filenames up to 42 characters long using the [[OEM character set]]<!-- not Unicode --> and be up to 4 <abbr title="gibibyte (1024 MiB or 1,048,576 KiB or 1,073,741,824 bytes)">GiB</abbr> minus 1 byte in size. The on-disk timestamps hold creation, modification and access dates and times but differ from FAT: in FAT, the [[Epoch (computing)|epoch]] is 1980; in FATX, the epoch is 2000.{{citation needed|date=January 2012}} On the [[Xbox 360]], the epoch is 1980.<ref name="Xbox360_FATX"/> |
|||
==== exFAT ==== |
|||
{{Main|exFAT}} |
|||
exFAT is an incompatible file system, introduced with [[Windows Embedded CE 6.0]] in November 2006 and brought to mainline Windows in [[Windows Vista#Service Pack 1|Vista Service Pack 1]]. It is loosely based on the File Allocation Table architecture, but proprietary and protected by patents. |
|||
The [[Master Boot Record|MBR]] [[partition type]] is <tt>[[Partition type#PID_07h|0x07]]</tt> (the same as used for [[Installable File System|IFS]], [[HPFS]], [[NTFS]], etc.). Logical geometry information located in the [[Volume Boot Record|VBR]] is stored in a format not resembling any kind of BPB. exFAT is intended for use on [[Flash drive (disambiguation)|flash drive]]s (such as [[SDXC]] and [[Memory Stick XC]]), where [[#FAT32|FAT32]] is otherwise used. |
|||
It offers several benefits over [[#FAT32|FAT32]] including breaking the 4 GiB [[Large file support|file size limit]] of standard FAT32 (contrast FAT+ above), being more space-efficient for files smaller than 64 KiB on large volumes and, compared to light-weight implementations of FAT32 in DOS and some embedded systems, it can offer faster seeks if more than a few thousand files are stored in a single sub-directory, whereas FAT32 is typically faster than exFAT for larger files as used on digital cameras, camcorders and media players or when flash cards are used mainly for archival purposes.{{citation needed|date=February 2014}} |
|||
Storage devices formatted as exFAT cannot exchange data with equipment not supporting the format. Most consumer electronics do not support exFAT, which requires acquisition of a commercial license from [[Microsoft]],<ref name="Microsoft_exFAT-License"/> which rules out its legal distribution as part of [[open source]] operating systems. |
|||
Beginning in [[Windows Vista]] SP1, Microsoft's [[Graphical User Interface|GUI]] and command-line format utilities now offer exFAT as an alternative to NTFS (and for smaller partitions, FAT16 and FAT32). |
|||
== Technical design == |
== Technical design == |
||
Line 2,005: | Line 1,823: | ||
<references group="nb"> |
<references group="nb"> |
||
<ref group="nb" name="NB_NCR_FAT">Sources differ in regard to the first NCR data entry terminal integrating support for the FAT file system. According to [[Stephen Manes]] and Paul Andrews, "Gates",<!-- <ref name="Manes_1993_Gates"/> --> development was for a NCR 8200 in late 1977, according to them a floppy-based upgrade to the NCR 7200, which was cassette-based (and is mentioned in other sources). [[Marc McDonald]] remembers<!-- in 2012-08 --> a NCR 8500. Another possible candidate is the 8080-based NCR 7500, which is known to have used 8"-floppies and was released in 1978.</ref> |
|||
<ref group="nb" name="NB_VFAT_Name">A driver named [[#VFAT|VFAT]] appeared before [[Windows 95]], in [[Windows for Workgroups]] 3.11, but this older version was only used for implementing [[32-bit file access]] and did not support [[long file name]]s.</ref> |
|||
<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_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 <tt>0xE5</tt> had a special meaning in directory entries.<!-- <ref name="Schulman_1994_Undocumented-DOS"/> --></ref> |
<ref group="nb" name="NB_Magic_E5">This is the reason, why <tt>0xE5</tt> had a special meaning in directory entries.<!-- <ref name="Schulman_1994_Undocumented-DOS"/> --></ref> |
||
Line 2,013: | Line 1,829: | ||
<ref group="nb" name="NB_Magic_AA55">The signature at offset <tt>0x1FE</tt> in boot sectors is <tt>0x55 0xAA</tt>, that is <tt>0x55</tt> at offset <tt>0x1FE</tt> and <tt>0xAA</tt> at offset <tt>0x1FF</tt>. Since [[little-endian]] representation must be assumed in the context of [[IBM PC]] compatible machines, this can be written as 16-bit word <tt>0xAA55</tt> in programs for [[Intel x86|x86]] processors (note the swapped order), whereas it would have to be written as <tt>0x55AA</tt> 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: http://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_AA55">The signature at offset <tt>0x1FE</tt> in boot sectors is <tt>0x55 0xAA</tt>, that is <tt>0x55</tt> at offset <tt>0x1FE</tt> and <tt>0xAA</tt> at offset <tt>0x1FF</tt>. Since [[little-endian]] representation must be assumed in the context of [[IBM PC]] compatible machines, this can be written as 16-bit word <tt>0xAA55</tt> in programs for [[Intel x86|x86]] processors (note the swapped order), whereas it would have to be written as <tt>0x55AA</tt> 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: http://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 [[checksum#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 <tt>0x1234</tt> 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_Magic_1234">The [[checksum#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 <tt>0x1234</tt> 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 <tt>0xFF0</tt> on FAT12 volumes under MS-DOS/PC DOS 3.3 and higher.</ref> |
<ref group="nb" name="NB_MAGIC_FF0">See other links for special precautions in regard to occurrences of a cluster value of <tt>0xFF0</tt> 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 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_DRDOS_Volume-Label">To avoid potential misinterpretation of directory volume labels with VFAT LFN entries by non-VFAT aware operating systems, the DR-DOS 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> |
||
Line 2,026: | Line 1,841: | ||
== References == |
== References == |
||
{{reflist|30em|refs= |
{{reflist|30em|refs= |
||
<ref name="BYTE_1980_86-DOS">{{cite web |
|||
|title=86-DOS - 8086 OPERATING SYSTEM - $95 |
|||
|author=Seattle Computer Products |
|||
|authorlink=Seattle Computer Products |
|||
|journal=[[Byte (magazine)|Byte]] |
|||
|volume=5 |
|||
|series=8 |
|||
|page=174 |
|||
|date=August 1980 |
|||
|url=http://archive.org/stream/byte-magazine-1980-08/1980_08_BYTE_05-08_The_Forth_Language#page/n173/mode/2up |
|||
|accessdate=2013-08-18}} (NB. The SCP advertisement already calls the product ''86-DOS'', but does not mention a specific version number. Version 0.3 is known to be called 86-DOS already, so the name change must have taken place either for version 0.2 or immediately afterwards in August 1980.)</ref> |
|||
<ref name="Microsoft_2010_FAT">{{cite web |
<ref name="Microsoft_2010_FAT">{{cite web |
||
|title=FAT File System (Windows Embedded CE 6.0) |
|title=FAT File System (Windows Embedded CE 6.0) |
||
Line 2,065: | Line 1,869: | ||
|id=8411-310-02, 036-014-012 |
|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> |
|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="Hunter_1983_Softalk">David Hunter (1983). ''Tim Paterson - The roots of DOS''. Softalk, ''IBM Personal Computer'', March 1983 ([http://www.patersontech.com/Dos/Softalk/Softalk.html]).</ref> |
|||
<ref name="Manes_1993_Gates">{{cite book| |
|||
first=Stephen|last=Manes|author2=Paul Andrews| |
|||
year=1993| |
|||
title=Gates: How Microsoft's Mogul Reinvented an Industry—and Made Himself the Richest Man in America| |
|||
publisher=Doubleday| |
|||
isbn=0-385-42075-7}}</ref> |
|||
<ref name="IBM_1984_PCDOS30">IBM (1984). ''IBM PC DOS 3.0 announcement letter''.</ref> |
|||
<ref name="IBM_1985_Reference">IBM (1985). ''IBM PC DOS Technical Reference''. First Edition, P/N 6024181, dated February 1985.</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 | accessdate = 2011-07-30 }}</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 | accessdate = 2011-07-30 }}</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 | accessdate = 2012-01-06 }}</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 | accessdate = 2012-01-06 }}</ref> |
||
Line 2,080: | Line 1,875: | ||
<ref name="Duncan_1988_MS-DOS_Encyclopedia">Ray Duncan (1988). ''The MS-DOS Encyclopedia - version 1.0 through 3.2''. Microsoft Press. ISBN 1-55615-049-0.</ref><!-- While mostly based on DOS 3.2, this book has an appendix covering changes introducted with DOS 3.3 --> |
<ref name="Duncan_1988_MS-DOS_Encyclopedia">Ray Duncan (1988). ''The MS-DOS Encyclopedia - version 1.0 through 3.2''. Microsoft Press. ISBN 1-55615-049-0.</ref><!-- While mostly based on DOS 3.2, this book has an appendix covering changes introducted with DOS 3.3 --> |
||
<ref name="Schulman_1994_Undocumented-DOS">{{cite book|first1=Andrew|last1=Schulman|first2=Ralf|last2=Brown|authorlink2=Ralf Brown|first3=David|last3=Maxey|first4=Raymond J.|last4=Michels|first5=Jim|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|year=1994|pages=11|isbn=0-201-63287-X|id=ISBN 978-0-201-63287-3}}</ref> |
<ref name="Schulman_1994_Undocumented-DOS">{{cite book|first1=Andrew|last1=Schulman|first2=Ralf|last2=Brown|authorlink2=Ralf Brown|first3=David|last3=Maxey|first4=Raymond J.|last4=Michels|first5=Jim|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|year=1994|pages=11|isbn=0-201-63287-X|id=ISBN 978-0-201-63287-3}}</ref> |
||
<ref name="Wallace_1992_Harddrive">Wallace & Erickson, 1992. ''Hard Drive''. John Wiley & Sons. ISBN 0-471-56886-4.</ref> |
|||
<ref name="Paterson_2007_Design-DOS">{{cite web | url = http://dosmandrivel.blogspot.com/2007/09/design-of-dos.html | date = 2007-09-30 | author = [[Tim Paterson]] | title = Design of DOS | work = DosMan Drivel | accessdate = 2011-07-04 }}</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="Norton2">[[Peter Norton]] (1986). ''Inside the IBM PC, Revised and Enlarged'', Brady. ISBN 0-89303-583-1, p. 157.</ref> |
||
<ref name="Jenkinson_2000_Forensic">{{cite book | author = Brian Jenkinson, Sammes, A. J. | title = Forensic Computing: A Practitioner's Guide (Practitioner Series) | publisher = Springer | location=Berlin | year = 2000 | page=157 | isbn=1-85233-299-9 | quote = "... only 2^12 (that is, 4096) allocation units or clusters can be addressed. In fact, the number is less than this, since 000h and 001h are not used and FF0h to FFFh are reserved or used for other purposes, leaving 002h to FEFh (2 to 4079) as the range of possible clusters."}}</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 | accessdate = 2011-07-03 }}</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 | accessdate = 2011-07-03 }}</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 | authorlink = Andries Brouwer }}</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 | authorlink = Andries Brouwer }}</ref> |
||
<ref name="Chappell_1994_DOS-Internals">Geoff Chappell (1994). ''DOS Internals''. Addison Wesley. ISBN 0-201-60835-9, ISBN 978-0-201-60835-9.</ref> |
<ref name="Chappell_1994_DOS-Internals">Geoff Chappell (1994). ''DOS Internals''. Addison Wesley. ISBN 0-201-60835-9, ISBN 978-0-201-60835-9.</ref> |
||
<ref name="Microsoft_69912">[http://support.microsoft.com/kb/q69912/ Microsoft Knowledge Base article: "MS-DOS Partitioning Summary"]</ref> |
|||
<ref name="Brouwer_2002_Partition-IDs">{{cite web | url = http://www.win.tue.nl/~aeb/partitions/partition_types-1.html | title = List of partition identifiers for PCs | author = Andries Brouwer | authorlink = Andries Brouwer }}</ref> |
|||
<ref name="Brouwer_2002_Logical_FAT">{{cite web | url = http://www.win.tue.nl/~aeb/partitions/partition_types-2.html#ss2.6 | title = Properties of partition tables | author = Andries Brouwer | authorlink = Andries Brouwer }}</ref> |
|||
<ref name="Microsoft_2003_CC736327">{{cite web | url = http://technet.microsoft.com/en-us/library/cc736327(v=ws.10).aspx | title = Dskprobe Overview: Data Recovery | publisher = [[Microsoft TechNet]] | date = 2003-03-28 | accessdate = 2011-08-03 }}</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 | accessdate = 2012-09-11}} |
<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 | accessdate = 2012-09-11}} |
||
</ref> |
</ref> |
||
<ref name="Microsoft_2004_KB120138">{{cite web | url = http://support.microsoft.com/kb/120138 | title = Errors Creating Files or Folders in the Root Directory | publisher = Microsoft Help and Support | date = December 16, 2004 | accessdate = 2006-10-14 }}</ref> |
|||
<ref name="Microsoft_1998_CC768180">{{cite web | url = http://technet.microsoft.com/en-us/library/cc768180.aspx | title = Windows 98 Resource Kit - Chapter 10 - Disks and File Systems | publisher = [[Microsoft TechNet]] | year = 1998 | accessdate = 2012-07-16 }}</ref> |
<ref name="Microsoft_1998_CC768180">{{cite web | url = http://technet.microsoft.com/en-us/library/cc768180.aspx | title = Windows 98 Resource Kit - Chapter 10 - Disks and File Systems | publisher = [[Microsoft TechNet]] | year = 1998 | accessdate = 2012-07-16 }}</ref> |
||
<ref name="MKDOSFS">{{cite web | url = http://www.die.net/doc/linux/man/man8/mkdosfs.8.html | title = mkdosfs man page }}</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 kilobytes (<abbr title="“kilobyte”; should be “kibibyte” (1024 or 2×512 bytes)">KB</abbr>) or larger | date = 2007-03-26 | publisher = [[Microsoft Knowledge Base]] | accessdate = 2011-08-21 }}</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 kilobytes (<abbr title="“kilobyte”; should be “kibibyte” (1024 or 2×512 bytes)">KB</abbr>) or larger | date = 2007-03-26 | publisher = [[Microsoft Knowledge Base]] | accessdate = 2011-08-21 }}</ref> |
||
<ref name="Microsoft_2007_KB314463">{{cite web | url = http://support.microsoft.com/kb/314463 | title = Limitations of the FAT32 File System in Windows XP | date = 2007-12-01 | publisher = [[Microsoft Knowledge Base]] | accessdate = 2011-08-21 }}</ref> |
|||
<ref name="Microsoft_1987_DOS33Ref">Microsoft (1987-07). ''MS-DOS 3.3 Programmer's Reference.''</ref> |
<ref name="Microsoft_1987_DOS33Ref">Microsoft (1987-07). ''MS-DOS 3.3 Programmer's Reference.''</ref> |
||
<ref name="GB4">{{cite web | url = http://technet.microsoft.com/en-us/library/cc938937.aspx | title = File Systems | year = 2001 | publisher = [[Microsoft TechNet]] | accessdate = 2011-07-31 }}</ref> |
<ref name="GB4">{{cite web | url = http://technet.microsoft.com/en-us/library/cc938937.aspx | title = File Systems | year = 2001 | publisher = [[Microsoft TechNet]] | accessdate = 2011-07-31 }}</ref> |
||
<ref name="Eager_2000_Tavi">{{cite web | url = http://www.tavi.co.uk/os2pages/eadata.html | title = Implementation of extended attributes on the FAT file system | author = Bob Eager | work = Tavi OS/2 pages | date = 2000-10-28 | accessdate = 2006-10-14 }}</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]).</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]).</ref> |
||
<ref name="Linux_ChangeLog257">{{cite web | url = http://www.kernel.org/pub/linux/kernel/v2.5/ChangeLog-2.5.7 | title = Release notes for v2.5.7 | publisher = The Linux Kernel archives | date = 2002-03-12 | accessdate = 2006-10-14 }}</ref> |
|||
<ref name="Xbox_FATX-Spec">{{cite web | url = http://www.free60.org/FATX | title = FATX Specification | publisher = free60 wiki | accessdate = 2011-08-16 }}</ref> |
|||
<ref name="Xbox_Linux">{{cite web | url = http://www.xbox-linux.org/wiki/Xbox_Partitioning_and_Filesystem_Details | title = Xbox partitioning and file system details | publisher = Xbox-Linux project }}</ref> |
|||
<ref name="Xbox360_FATX">{{cite web | url = http://www.xbox-linux.org/wiki/Differences_between_Xbox_FATX_and_MS-DOS_FAT | title = Differences between Xbox FATX and MS-DOS FAT | publisher = Xbox-Linux project }}</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]).</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]).</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]).</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]).</ref> |
||
Line 2,162: | Line 1,942: | ||
<ref name="ArsTechnica_2009">{{cite web | url = http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/ | title = New Linux patch could circumvent Microsoft’s FAT patents | last= Paul | first = Ryan | date=2009-07-02 | accessdate = 2013-10-30 | publisher=ArsTechnica.com}}</ref> |
<ref name="ArsTechnica_2009">{{cite web | url = http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/ | title = New Linux patch could circumvent Microsoft’s FAT patents | last= Paul | first = Ryan | date=2009-07-02 | accessdate = 2013-10-30 | publisher=ArsTechnica.com}}</ref> |
||
<ref name="Brown_2002_INTER61">{{cite web|url=http://www.cs.cmu.edu/~ralf/files.html|title=The x86 Interrupt List|date=2002-12-29|accessdate=2011-10-14|author=Ralf Brown}}</ref> |
<ref name="Brown_2002_INTER61">{{cite web|url=http://www.cs.cmu.edu/~ralf/files.html|title=The x86 Interrupt List|date=2002-12-29|accessdate=2011-10-14|author=Ralf Brown}}</ref> |
||
<ref name="Microsoft_2000_Wyse-DOS">Microsoft (2000-12-17). ''Wyse DOS 3.3 Partitions Incompatible with MS-DOS 5.x and 6.x''. Document Q78407 ([ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q78/4/07.TXT]).</ref> |
|||
<ref name="Microsoft_2000_Logical-sectoring">Microsoft (2000-12-17). ''Upgrading Pre-4.0 Systems with Logical Drive(s) > 32 MB''. Document Q68176 ([ftp://ftp.microsoft.com/misc1/PEROPSYS/MSDOS/KB/Q68/1/76.TXT]).</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|accessdate=2013-03-10}}</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|accessdate=2013-03-10}}</ref> |
||
<ref name="Microsoft_exFAT-License">{{cite web|url=http://www.microsoft.com/en-us/legal/intellectualproperty/IPLicensing/Programs/exFATFileSystem.aspx|title=exFAT File System Intellectual Property licensing program|author=Microsoft|accessdate=2013-04-23}}</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|accessdate=2011-04-13}}</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|accessdate=2011-04-13}}</ref> |
||
<ref name="_1992_LFNs">{{cite web|title= |
<ref name="_1992_LFNs">{{cite web|title= |
Revision as of 22:31, 14 May 2014
![]() | This article may be too long to read and navigate comfortably. (March 2013) |
Developer(s) | Microsoft, SCP, IBM, Compaq, Digital Research, Novell |
---|---|
Full name | File Allocation Table: FAT12 (12-bit version), FAT16/FAT16B/FAT16X (16-bit versions), FAT32/FAT32X (32-bit version with 28 bits used) |
Introduced | 1977 (Standalone Disk BASIC-80) FAT12: August 1980 (SCP QDOS) FAT16: August 1984 (IBM PC DOS 3.0) FAT16B: November 1987 (Compaq MS-DOS 3.31) FAT16X: August 1995 (Windows 95) FAT32/FAT32X: August 1996 (Windows 95 OSR2) |
Partition IDs | MBR/EBR: FAT12: 0x01 H:0x11/0x8D S:0xC1/0xD1 FAT16: 0x04 H:0x14/0x90 S:0xC4/0xD4 FAT16B: 0x06 H:0x16/0x92 S:0xC6/0xD6 FAT16X: 0x0E H:0x1E/0x9A S:0xCE FAT32: 0x0B H:0x1B/0x97 S:0xCB FAT32X: 0x0C H:0x1C/0x98 S:0xCC Logical sectored FAT12/FAT16: 0x08 0x11 0x14 0x24 0x56 0xE5 0xF2 BDP: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 |
Structures | |
Directory contents | Table |
File allocation | Linked list |
Bad blocks | Cluster tagging |
Limits | |
Max volume size | FAT12: 32 MiB (256 MiB for 64 KiB clusters) FAT16: 2 GiB (4 GiB for 64 KiB clusters) FAT32: 2 TiB (16 TiB for 4 KiB sectors) |
Max file size | 4,294,967,295 bytes (4 GiB - 1) with FAT16B and FAT32[1] 274,877,906,943 bytes (256 GiB - 1) only with FAT32+[2] |
Max no. of files | FAT12: 4,068 for 8 KiB clusters FAT16: 65,460 for 32 KiB clusters FAT32: 268,173,300 for 32 KiB clusters |
Max filename length | 8.3 filename, or 255 UCS-2 characters when using LFN |
Features | |
Dates recorded | Modified date/time, creation date/time (DOS 7.0 and higher only), access date (only available with ACCDATE enabled),[3] deletion date/time (only with DELWATCH 2) |
Date range | 1980-01-01 to 2099-12-31 (2107-12-31) |
Date resolution | 2 seconds for last modified time, 10 ms for creation time, 1 day for access date, 2 seconds for deletion time |
Forks | Not natively |
Attributes | Read-only, Hidden, System, Volume, Directory, Archive |
File system permissions | FAT12/FAT16: File, directory and volume access rights for Read, Write, Execute, Delete only with DR-DOS, PalmDOS, Novell DOS, OpenDOS, FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager, REAL/32 (Execute right only with FlexOS, 4680 OS, 4690 OS; individual file / directory passwords not with FlexOS, 4680 OS, 4690 OS; World/Group/Owner permission classes only with multiuser security loaded) FAT32: Partial, only with DR-DOS, REAL/32 and 4690 OS |
Transparent compression | FAT12/FAT16: Per-volume, SuperStor, Stacker, DoubleSpace, DriveSpace FAT32: No |
Transparent encryption | FAT12/FAT16: Per-volume only with DR-DOS FAT32: No |
File Allocation Table (FAT) is the name of a computer file system architecture and a family of industry-standard file systems utilizing it.
The FAT file system is a legacy file system which is simple and robust.[4] It offers good performance even in light-weight implementations, but cannot deliver the same performance, reliability and scalability as some modern file systems. It is, however, supported for compatibility reasons by nearly all currently developed operating systems for personal computers and many mobile devices and embedded systems, and thus is a well-suited format for data exchange between computers and devices of almost any type and age from the early 1980s (when it was introduced) up to the present.[citation needed]
Originally designed in the late 1970s for use on floppy disks, FAT was soon adapted and used almost universally on hard disks throughout the DOS and Windows 9x eras for two decades. With the introduction of more powerful computers and operating systems, as well as the development of more complex file systems for them, FAT is no longer the default file system for usage on Microsoft Windows computers.[5]
Today, FAT file systems are still commonly found on floppy disks, USB sticks, flash and other solid-state memory cards and modules, and many portable and embedded devices. DCF implements FAT as the standard file system for digital cameras. FAT is also utilized in the boot stage of EFI-compliant computers.
The name of the file system originates from the file system's prominent usage of an index table, the FAT, statically allocated at the time of formatting. The table contains entries for each cluster, a contiguous area of disk storage. Each entry contains either the number of the next cluster in the file, or else a marker indicating end of file, unused disk space, or special reserved areas of the disk. The root directory of the disk contains the number of the first cluster of each file in that directory; the operating system can then traverse the FAT table, looking up the cluster number of each successive part of the disk file as a cluster chain until the end of the file is reached. In much the same way, sub-directories are implemented as special files containing the directory entries of their respective files.
As disk drives have evolved, the maximum number of clusters has significantly increased, and so the number of bits used to identify each cluster has grown. The successive major versions of the FAT format are named after the number of table element bits: 12 (FAT12), 16 (FAT16), and 32 (FAT32). Each of these variants is still in use. The FAT standard has also been expanded in other ways while generally preserving backward compatibility with existing software.
Overview
Uses
The FAT file system offers reasonably good performance and robustness, even in very light-weight implementations.[4] It is therefore widely adopted and supported by virtually all existing operating systems for personal computers as well as some home computers and a multitude of embedded systems. This makes it a useful format for solid-state memory cards and a convenient way to share data between operating systems.
FAT file systems are the default file system for removable media (with the exception of CDs and DVDs) and as such are commonly found on floppy disks, super-floppies, memory and flash memory cards or USB flash drives and are supported by most portable devices such as PDAs, digital cameras, camcorders, media players, or mobile phones. While FAT12 is omnipresent on floppy disks, FAT16 and FAT32 are typically found on the larger media.
FAT was also commonly used on hard disks throughout the DOS and Windows 9x eras, but its use on hard drives has declined since the introduction of Windows XP, which primarily uses the newer NTFS. FAT is still used in hard drives expected to be used by multiple operating systems, such as in shared Windows, Linux and DOS environments.
Due to the widespread use of FAT-formatted media, many operating systems provide support for FAT through official or third-party file system handlers. For example, Linux, FreeBSD, BeOS and JNode provide inbuilt support for FAT, even though they also support more sophisticated file systems such as ext4 or btrfs. Mac OS 9 and Mac OS X support FAT file systems on volumes other than the boot disk. AmigaOS supports FAT through the CrossDOS package.
For many purposes, the NTFS file system is superior to FAT in terms of features and reliability; its main drawbacks are the size overhead for small volumes and the very limited support by anything other than the NT-based versions of Windows, since the exact specification is a trade secret of Microsoft. The availability of NTFS-3G since mid-2006 has led to much improved NTFS support in Unix-like operating systems, considerably alleviating this concern. It is still not possible to use NTFS in DOS-like operating systems without third-party drivers, which in turn makes it difficult to use a DOS floppy for recovery purposes. Microsoft provided a recovery console to work around this issue, but for security reasons it severely limited what could be done through the Recovery Console by default. The movement of recovery utilities to boot CDs based on BartPE, Linux (with NTFS-3G), or WinPE is finally eroding this drawback.
FAT has a long history (over three decades) of usage on desktops and portable computers, and it is frequently used in embedded solutions. As such, it continues to be the most widespread file system worldwide.
The DCF file system adopted by almost all digital cameras since 1998 defines a logical file system with 8.3 filenames and makes the usage of either FAT12, FAT16, FAT32 or exFAT mandantory for its physical layer in order to maximize platform interoperability.[6]
FAT is also utilized internally for the EFI system partition (partition type 0xEF) in the boot stage of EFI-compliant computers.
For floppy disks, FAT has been standardized as ECMA-107[7] and ISO/IEC 9293:1994[8] (superseding ISO 9293:1987[9]). These standards cover FAT12 and FAT16 with only short 8.3 filename support; long filenames with VFAT are partially patented.[10]
Nomenclature
Technically, the term "FAT file system" refers to all three major variants of the file system, FAT12, FAT16 and FAT32, and most parties clearly distinguish between them where necessary. In contrast to this, Microsoft typically no longer distinguishes between all three of them since the introduction of FAT32, and refers to both FAT12 and FAT16 as "FAT", whereas "FAT32" gets treated specially in dialog boxes and documentation. This can sometimes lead to confusion if the actual type of the file system used is not mentioned or cannot be explicitly specified (e.g., "Do you want to format as FAT or FAT32?" instead of "Do you want to format as FAT12, FAT16 or FAT32?").
Another common cause of confusion exists within the group of FAT16 file systems, since the term "FAT16" refers to both, either the whole group of FAT file systems with 16-bit wide cluster entries, or specifically only the original implementation of it with 16-bit sector entries, when it becomes necessary to differentiate between the original and the later implementation. While technically the newer variant with 32-bit sector entries is called "FAT16B", it is commonly referred to under the name "FAT16" as well, in particular since the original variant is rarely seen today and typically only used on small media when backward compatibility with DOS before 3.31 is required.
Further, the term "VFAT" has led to various misconceptions as well, as it is sometimes erroneously used as if it would describe another variant of FAT file system to be distinguished from the FAT12, FAT16 and FAT32 file systems, while in reality it does not specify another file system, but an optional extension, which can work on top of any FAT file system, FAT12, FAT16 or FAT32. Volumes utilizing VFAT long-filenames can be read also by operating systems not supporting the VFAT extension, for as long as they support the underlying file system.
In order to be technically correct and exact, this article uses standard prefixes for the byte unit: 1000 bytes (103 bytes) are 1 kB (kilobyte) and 1024 bytes (210 bytes) equal 1 KiB (kibibyte) etc.
Historical evolution
The FAT file system was first implemented in the 1970s by Microsoft. Since then it has undergone significant evolution in support of increased storage capacity and functionality. Different variants and versions of the file system were introduced along the way. Different versions are not necessarily implemented by Microsoft nor are they necessarily compatible with one another.
Technical design
![]() |
Layout
Contents | Boot Sector | FS Information Sector (FAT32 only) | More reserved sectors (optional) | File Allocation Table #1 | File Allocation Table #2 ... (conditional) | Root Directory (FAT12/FAT16 only) | Data Region (for files and directories) ... (to end of partition or disk) |
---|---|---|---|---|---|---|---|
Size in sectors | (number of reserved sectors) | (number of FATs) * (sectors per FAT) | (number of root entries*32) / (bytes per sector) | (number of clusters) * (sectors per cluster) |
A FAT file system is composed of four different sections:
- The Reserved sectors, located at the very beginning.
- The first reserved sector (logical sector 0) is the Boot Sector (aka Volume Boot Record (VBR)). It includes an area called the BIOS Parameter Block (with 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.[11]
- For FAT32 file systems, the reserved sectors include a File System Information Sector at logical sector 1 and a Backup Boot Sector at logical sector 6.
- While many other vendors have continued to utilize a single-sector setup (logical sector 0 only) for the bootstrap loader, Microsoft's boot sector code has grown to spawn 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.
- The FAT Region.
- This typically contains two copies (may vary) of the File Allocation Table for the sake of redundancy checking, although rarely used, even by disk repair utilities.
- These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors.
- Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. In FAT32, it is possible to switch from the default behaviour and select a single FAT out of the available ones to be used for diagnosis purposes.
- The first two clusters (cluster 0 and 1) in the map contain special values.
- The Root Directory Region.
- This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here.
- The Data Region.
- This is where the actual file and directory data is stored and takes up most of the partition. Traditionally, the unused parts of the data region are initialized with a filler value of 0xF6 as per the INT 1Eh's Disk Parameter Table (DPT) during format on IBM compatible machines, but also used on the Atari Portfolio. 8-inch CP/M floppies typically came pre-formatted with a value of 0xE5;[12] by way of Digital Research this value was also used on Atari ST formatted floppies.[nb 1] Amstrad used 0xF4 instead. Some modern formatters wipe hard disks with a value of 0x00, whereas a value of 0xFF, the default value of a non-programmed flash block, is used on flash disks to reduce wear. The latter value is typically also used on ROM disks. (Some advanced formating tools allow to configure the format filler byte.[nb 2])
- The size of files and subdirectories can be increased arbitrarily (as long as there are free clusters) by simply adding more links to the file's chain in the FAT. Note however, that files are allocated in units of clusters, so if a 1 KiB file resides in a 32 KiB cluster, 31 KiB are wasted.
- 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). 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.
Boot Sector
On non-partitioned devices, such as floppy disks, the Boot Sector (VBR) is the first sector (logical sector 0 with physical CHS address 0/0/1 or LBA address 0). For partitioned devices such as hard drives, the first sector is the Master Boot Record defining partitions, while the first sector of partitions formatted with a FAT file system is again the Boot Sector.
Common structure of the first 11 bytes used by most FAT versions for IBM compatible x86-machines since DOS 2.0 are:
Byte Offset | Length (bytes) | Description |
---|---|---|
0x000 | 3 | Jump instruction. If the boot sector has a valid signature residing in the 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 0xEB 0x?? 0x90[13][14] as seen since DOS 3.0[nb 3]—and on DOS 1.1[15][16]) or a near jump (0xE9 0x?? 0x??[13][14] as seen on DOS 2.x formatted disks). For backward compatibility MS-DOS, PC DOS and DR-DOS also accept a jump (0x69 0x?? 0x??)[13][14][17] on removable disks. On hard disks, DR DOS additionally accepts the swapped JMPS sequence starting with a NOP (0x90 0xEB 0x??), whereas MS-DOS/PC 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 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) 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 sector 1). |
0x003 | 8 | OEM Name (padded with spaces 0x20). This value determines in which system the disk was formatted.
Although officially documented as free for OEM use, MS-DOS/PC DOS (since 3.1), Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied upon and how to interpret them. Therefore, setting the OEM label to arbitrary or bogus values may cause MS-DOS, PC DOS and OS/2 to not recognize the volume properly and cause data corruption on writes.[18][19][20] Common examples are " 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 " Some boot loaders make adjustments or refuse to pass control to a boot sector depending on certain values detected here (e.g., NEWLDR offset 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 " |
0x00B | varies | BIOS Parameter Block (13, 19, 21 or 25 bytes), Extended BIOS Parameter Block (32 or 51 bytes) or FAT32 Extended BIOS Parameter Block (79 bytes); size and contents varies between operating systems and versions, see below |
varies | varies | File system and operating system specific boot code; often starts immediately behind [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. |
0x1FD | 1 | 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 0x024 (at offset 0x19 in the EBPB). Most Microsoft and IBM boot sectors maintain values of 0x00 at offset 0x1FC and 0x1FD ever since, although they are not part of the signature at 0x1FE.
If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset 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 VBR code ignores the DL value. |
0x1FE | 2 | Boot sector signature (0x55 0xAA).[11][nb 4] This signature indicates an IBM PC compatible boot code and is tested by most boot loaders residing in the System BIOS or the MBR before passing execution to the boot sector's boot code (but, e.g., not by the original IBM PC ROM-BIOS[22]). 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[15][16] 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 DOS prior to 3.3 checked this signature, but newer issues as well as DR-DOS 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 (0xF4 0xEB 0xFD) or issue an INT 19h and RETF (0xCD 0x19 0xCB). These opstrings should not be used at sector offset 0x000, however, because DOS tests for other opcodes as signatures. Many MSX-DOS 2 floppies use 0xEB 0xFE 0x90 at sector offset 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 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 STs will assume a disk to be Atari 68000 bootable if the checksum over the 256 big-endian words of the boot sector equals 0x1234.[23][nb 5] 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 0xAA 0x55 has been observed on disk images. This can be the result of a faulty implementation in the formating tool based on faulty documentation,[nb 4] 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. |
FAT-formatted Atari ST floppies have a very similar boot sector layout:
Byte Offset | Length (bytes) | Description |
---|---|---|
0x000 | 2 | Jump instruction. Original Atari ST boot sectors start with a 68000 BRA.S instruction (0x60 0x??). For compatibility with PC operating systems, Atari ST formatted disks since TOS 1.4 start with 0xE9 0x?? instead. |
0x002 | 6 | OEM Name (padded with spaces 0x20), e.g., "Loader " (0x4C 0x6F 0x61 0x64 0x65 0x72) on volumes containing an Atari ST boot loader. See OEM Name precautions for PC formatted disks above. Note the different offset and length of this entry compared to the entry on PC formatted disks.
|
0x008 | 3 | Disk serial number (default: 0x00 0x00 0x00), used by Atari ST to detect a disk change. (Windows 9x Volume Tracker will always store "IHC " 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.
|
0x00B | 19 | DOS 3.0 BIOS Parameter Block (little-endian format) |
0x01E | varies | Private boot sector data (mixed big-endian and little-endian format) |
varies | varies | File system and operating system specific Atari ST boot code. No assumptions must be made in regard to the load position of the code, which must be relocatable. If loading an operating system fails, the code can return to the Atari ST BIOS with a 68000 RTS (opcode 0x4E75 with big-endian byte sequence 0x4E 0x75[nb 4]) instruction and all registers unaltered. |
0x1FE | 2 | Checksum. The 16-bit checksum over the 256 big-endian words of the 512 bytes boot sector including this word must match the magic value 0x1234 in order to indicate an Atari ST 68000 executable boot sector code.[23] This checksum entry can be used to align the checksum accordingly.[nb 5]
If the logical sector size is larger than 512 bytes, the remainder is not included in the checksum and is typically zero-filled.[23] Since some PC operating systems erroneously do not accept FAT formatted floppies if the 0x55 0xAA[nb 4] signature is not present here, it is advisable to place the 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 0x1234[nb 5] is not matched (unless the shared fat code overlay would be both IBM PC and Atari ST executable at the same time). |
FAT12-formatted MSX-DOS volumes have a very similar boot sector layout:
Byte Offset | Length (bytes) | Description |
---|---|---|
0x000 | 3 | Dummy jump instruction (e.g., 0xEB 0xFE 0x90). |
0x003 | 8 | OEM Name (padded with spaces 0x20). |
0x00B | 19 | DOS 3.0 BPB |
0x01E | varies (2) | 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 0x18 0xFE for JR 0x01E). |
0x020 | 6 | MSX-DOS 2 volume signature "VOL_ID ".
|
0x026 | 1 | MSX-DOS 2 undelete flag (default: 0x00. If the "VOL_ID " signature is present at sector offset 0x020, this flag indicates, if the volume holds deleted files which can be undeleted (see offset 0x0C in directory entries).
|
0x027 | 4 | MSX-DOS 2 disk serial number (default: 0x00000000). If the "VOL_ID " signature is present at sector offset 0x020, MSX-DOS 2 stores a volume serial number here for media change detection.
|
0x02B | 5 | reserved |
0x030 | varies (2) | 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 0x18 0xFE for JR 0x030). |
0x1FE | 2 | Signature |
BIOS Parameter Block
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 0x00B to 0x017 are stored since DOS 2.0, but not always used before DOS 3.2, values at 0x018 to 0x01B are used since DOS 3.0):
Sector Offset | BPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 2 | Bytes per logical sector in powers of two; 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 65535 logical sectors is 32 bytes, or 64 bytes for more than 65535 logical sectors. The minimum practical value is 128. Some pre-DOS 3.31 OEM versions of DOS used logical sector sizes up to 8192 bytes for logical sectored FATs. Atari ST GEMDOS supports logical sector sizes between 512 and 4096.[23] DR-DOS supports booting off FAT12/FAT16 volumes with logical sector sizes up to 32 KiB and INT 13h implementations supporting physical sectors up to 1024 bytes/sector. The minimum logical sector size for standard FAT32 volumes is 512 bytes, which can be reduced downto 128 bytes without support for the FS Information Sector. Floppy drives and controllers use physical sector sizes of 128, 256, 512 and 1024 bytes (e.g., PC/AX). The Atari Portfolio supports a sector size of 512 for volumes larger than 64 KiB, 256 bytes for volumes larger 32 KiB and 128 bytes for smaller volumes. Magneto-optical drives used sector sizes of 512, 1024 and 2048 bytes. In 2005 some Seagate custom hard disks used sector sizes of 1024 bytes instead of the default 512 bytes.[24] 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. |
0x00D | 0x02 | 1 | Logical sectors per cluster. Allowed values are 1, 2, 4, 8, 16, 32, 64, and 128. Some MS-DOS 3.x versions supported a maximum cluster size of 4 KiB only, whereas modern MS-DOS/PC DOS and Windows 95 support a maximum cluster size of 32 KiB. Windows 98/SE/ME partially support a cluster size of 64 KiB as well, but some FCB services are not available on such disks and various applications fail to work. The Windows NT family and some alternative DOS versions such as PTS-DOS fully support 64 KiB clusters. For DOS-based operating systems, the maximum cluster size remains at 32 KiB or 64 KiB even for sector sizes larger than 512 bytes. MS-DOS/PC DOS will hang on startup if this value is erroneously specified as 0.[25] |
0x00E | 0x03 | 2 | Count of reserved logical sectors. The number of logical sectors before the first FAT in the file system image. At least 1 for this sector, usually 32 for FAT32 (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. |
0x010 | 0x05 | 1 | Number of File Allocation Tables. Almost always 2; RAM disks might use 1. Most versions of MS-DOS/PC DOS do not support more than 2 FATs. Some DOS operating systems support only two FATs in their built-in disk driver, but support other FAT counts for block device drivers loaded later on.
Volumes declaring 2 FATs in this entry will never be treated as TFAT volumes. If the value differs from 2, some Microsoft operating systems may attempt to mount the volume as a TFAT volume and use the second cluster (cluster 1) of the first FAT to determine the TFAT status. |
0x011 | 0x06 | 2 | Maximum number of FAT12 or FAT16 root directory entries. 0 for FAT32, where the root directory is stored in ordinary data clusters; see offset 0x02C in FAT32 EBPBs.
This value must be adjusted so that directory entries always consume full logical sectors, whereby each directory entry takes up 32 bytes. MS-DOS/PC DOS require this value to be a multiple of 16. The maximum value supported on floppy disks is 240, the maximum value supported by MS-DOS/PC DOS on hard disks is 512. DR-DOS supports booting off FAT12/FAT16 volumes, if the boot file is located in the first 2048 root directory entries. |
0x013 | 0x08 | 2 | Total logical sectors (if zero, use 4 byte value at offset 0x020) |
0x015 | 0x0A | 1 | Media descriptor (compare: FAT ID):[26][27][28][nb 3]
This value must reflect the media descriptor stored (in the entry for cluster 0) in the first byte of each copy of the FAT. Certain operating systems before DOS 3.2 (86-DOS, MS-DOS/PC 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 0xF0 since DOS 4.0. On removable drives, DR-DOS will assume the presence of a BPB if this value is greater or equal to 0xF0, whereas for fixed disks, it must be 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 0xF8 or 0xFA to 0xFF MS-DOS/PC DOS treats bit 1 as a flag to choose a 9-sectors per track format rather than an 8-sectors format, and bit 0 as a flag to indicate double-sided media.[14] Values 0x00 to 0xEF and 0xF1 to 0xF7 are reserved and must not be used. |
0x016 | 0x0B | 2 | Logical sectors per File Allocation Table for FAT12/FAT16, 0 for FAT32 (cf. offset 0x024 below) |
DOS 3.0 BPB:
The following extensions were documented since DOS 3.0, however, they were already supported by some issues 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.
Sector Offset | BPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 13 | DOS 2.0 BPB |
0x018 | 0x0D | 2 | Physical sectors per track for disks with INT 13h CHS geometry,[11] e.g., 15 for a “1.20 MB” (1200 KiB) floppy.
A zero entry indicates that this entry is reserved, but not used. |
0x01A | 0x0F | 2 | Number of heads for disks with INT 13h CHS geometry,[11] e.g., 2 for a double sided floppy.
A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used. |
0x01C | 0x11 | 2 | Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned. This DOS 3.0 entry is incompatible with a similar entry at offset 0x01C in BPBs since DOS 3.31.
It must not be used if the logical sectors entry at offset 0x013 is zero. |
DOS 3.2 BPB:
Officially, MS-DOS 3.20 still used the DOS 3.0 format, but SYS and FORMAT were adapted to support a 6 bytes longer format already (of which not all entries were used).
Sector Offset | BPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 19 | DOS 3.0 BPB |
0x01E | 0x13 | 2 | Total logical sectors including hidden sectors. This DOS 3.2 entry is incompatible with a similar entry at offset 0x020 in BPBs since DOS 3.31.
It must not be used if the logical sectors entry at offset 0x013 is zero. |
DOS 3.31 BPB:
Officially introduced with DOS 3.31 and not used by DOS 3.2, some DOS 3.2 utilities were designed to be aware of this new format already. Official documentation recommends to trust these values only if the logical sectors entry at offset 0x013 is zero.
Sector Offset | BPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 13 | DOS 2.0 BPB |
0x018 | 0x0D | 2 | Physical sectors per track for disks with INT 13h CHS geometry,[11] e.g., 18 for a “1.44 MB” (1440 KiB) floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0.
A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated. |
0x01A | 0x0F | 2 | Number of heads for disks with INT 13h CHS geometry,[11] e.g., 2 for a double sided floppy. Unused for drives, which don't support CHS access any more. Identical to an entry available since DOS 3.0.
A bug in all versions of MS-DOS/PC DOS up to including 7.10 causes these operating systems to crash for CHS geometries with 256 heads, therefore almost all BIOSes choose a maximum of 255 heads only. A zero entry indicates that this entry is reserved, but not used. A value of 0 may indicate LBA-only access, but may cause a divide-by-zero exception in some boot loaders, which can be avoided by storing a neutral value of 1 here, if no CHS geometry can be reasonably emulated. |
0x01C | 0x11 | 4 | Count of hidden sectors preceding the partition that contains this FAT volume. This field should always be zero on media that are not partitioned.[7][8][9] This DOS 3.31 entry is incompatible with a similar entry at offset 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 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 0x1B6 in the AAP or NEWLDR MBR, so that it becomes possible to boot the operating system from EBRs. |
0x020 | 0x15 | 4 | Total logical sectors (if greater than 65535; otherwise, see offset 0x013). This DOS 3.31 entry is incompatible with a similar entry at offset 0x01E in DOS 3.2-3.3 BPBs. Officially, it must be used only if the logical sectors entry at offset 0x013 is zero, but some operating systems (some old versions of DR DOS) use this entry also for smaller disks. |
A simple formula translates a volume's given cluster number CN
to a logical sector number LSN
:[7][8][9]
- Determine (once)
SSA=RSC+FN×SF+ceil((32×RDE)/SS)
, where the reserved sector countRSC
is stored at offset 0x00E, the FAT numberFN
at offset 0x010, the sectors per FATSF
at offset 0x016 (FAT12/FAT16) or 0x024 (FAT32), the root directory entriesRDE
at offset 0x011, the sector sizeSS
at offset 0x00B, andceil(x)
rounds up to a whole number. - Determine
LSN=SSA+(CN-2)×SC
, where the sectors per clusterSC
are stored at offset 0x00D.
On unpartitioned media the volume's number of hidden sectors is zero and therefore LSN
and LBA
addresses become the same for as long as a volume's logical sector size is identical to the underlying medium's physical sector size. Under these conditions, it is also simple to translate between CHS
addresses and LSNs
as well:
LSN=SPT×(HN+(NOS×TN))+SN-1
, where the sectors per track SPT
are stored at offset 0x018, and the number of sides NOS
at offset 0x01A. Track number TN
, head number HN
, and sector number SN
correspond to Cylinder-head-sector: the formula gives the known CHS to LBA translation.
Extended BIOS Parameter Block
Further structure used by FAT12 and FAT16 since OS/2 1.0 and DOS 4.0, also known as Extended BIOS Parameter Block (EBPB) (bytes below sector offset 0x024 are the same as for the DOS 3.31 BPB):
Sector Offset | EBPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 25 | DOS 3.31 BPB |
0x024 | 0x19 | 1 | Physical drive number (0x00 for (first) removable media, 0x80 for (first) fixed disk as per INT 13h). Allowed values for possible physical drives depending on BIOS are 0x00-0x7E and 0x80-0xFE. Values 0x7F and 0xFF are reserved for internal purposes such as remote or ROM boot and should never occur on disk. Some boot loaders such as the MS-DOS/PC DOS boot loader use this value when loading the operating system, others ignore it altogether or use the drive number provided in the DL register by the underlying boot loader (e.g., with many BIOSes and MBRs). The entry is sometimes changed by SYS tools 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 0x1FD. If this belongs to a boot volume, the DR-DOS 7.07 enhanced MBR can be configured (see NEWLDR offset 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 VBR code ignores the DL value. |
0x025 | 0x1A | 1 | Reserved;
|
0x026 | 0x1B | 1 | Extended boot signature. (Should be 0x29[7][8][9][26] to indicate that an EBPB with the following 3 entries exists (since OS/2 1.2 and DOS 4.0). Can be 0x28 on some OS/2 1.0-1.1 and PC DOS 3.4 disks indicating an earlier form of the EBPB format with only the serial number following. MS-DOS/PC DOS 4.0 and higher, OS/2 1.2 and higher as well as the Windows NT family recognize both signatures accordingly.) |
0x027 | 0x1C | 4 | 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)[nb 6] and INT 21h/AH=2Ch (get system time)[nb 6] 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 |
0x02B | 0x20 | 11 | Partition Volume Label, padded with blanks (0x20), e.g., "NO␠NAME␠␠␠␠ " Software changing the directory volume label in the file system should also update this entry, but not all software does. The partition volume label is typically displayed in partitioning tools since it is accessible without mounting the volume. Supported since OS/2 1.2 and MS-DOS 4.0 and higher.
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 1Eh pointer to retrieve the ROM table as in later issues of the boot sector. The re-usage of this location for the mostly cosmetical partition volume label minimized problems if some older system utilities would still attempt to patch the former DPT. |
0x036 | 0x2B | 8 | File system type, padded with blanks (0x20), e.g., "FAT12␠␠␠ ", "FAT16␠␠␠ ", "FAT␠␠␠␠␠ "
This entry is meant for display purposes only and must not be used by the operating system to identify the type of the file system. Nevertheless, it is sometimes used for identification purposes by third-party software and therefore the values should not differ from those officially used. Supported since OS/2 1.2 and MS-DOS 4.0 and higher. |
FAT32 Extended BIOS Parameter Block
In essence FAT32 inserts 28 bytes into the EBPB, followed by the remaining 26 EBPB bytes as shown above for FAT12 and FAT16. Microsoft and IBM operating systems determine the type of FAT file system used on a volume solely by the number of clusters, not by the used BPB format or the indicated file system type, that is, it is technically possibly 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,[nb 7] operating systems should be prepared to cope with these hybrid forms.
Sector Offset | FAT32 EBPB Offset | Length (bytes) | Description |
---|---|---|---|
0x00B | 0x00 | 25 | DOS 3.31 BPB |
0x024 | 0x19 | 4 | Logical sectors per file allocation table (corresponds with the old entry at offset 0x0B in the DOS 2.0 BPB).
The byte at offset 0x026 in this entry should never become 0x28 or 0x29 in order to avoid any misinterpretation with the EBPB format under non-FAT32 aware operating systems. |
0x028 | 0x1D | 2 | Drive description / mirroring flags (bits 3-0: zero-based number of active FAT, if bit 7 set.[11] 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 0110:1111b (low-case letter 'o', bit 13 set for CHS access) or 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 0x034), displayed either in mixed or upper case, thereby indicating which access type failed). Formating tools or non-DR SYS-type tools may clear these bits, but other disk tools should leave bits 15-8 unchanged. |
0x02A | 0x1F | 2 | Version (defined as 0.0). The high byte of the version number is stored at offset 0x02B, and the low byte at offset 0x02A.[11] FAT32 implementations should refuse to mount volumes with version numbers unknown by them.
The FAT+ specification proposes to change the version number of FAT32+ volumes with file exceeding the standard FAT32 file size limit of 4 GiB - 1 to a version number 0.1 to keep implementations unaware of this extension from mounting the volume. Aware implementations should still mount and expect FAT+ large file entries on volumes with a version number 0.0 for maximum compatibility.[2] |
0x02C | 0x21 | 4 | Cluster number of root directory start, typically 2 (first cluster[33]) 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 0 is not officially allowed and can never indicate a valid root directory start cluster. Some non-standard FAT32 implementations may treat it as an indicator to search for a fixed-sized root directory where it would be expected on FAT16 volumes; see offset 0x011. |
0x030 | 0x25 | 2 | Logical sector number of FS Information Sector, typically 1, i.e., the second of the three FAT32 boot sectors.
Some FAT32 implementations support a slight variation of Microsoft's specification in making the FS Information Sector optional by specifying a value of 0xFFFF[25] (or 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, file system implementations should never attempt to use logical sector 0 as FS Information sector and instead assume that the feature is unsupported on that particular volume. Without a FS Information Sector, the minimum allowed logical sector size of FAT32 volumes can be reduced downto 128 bytes for special purposes. |
0x032 | 0x27 | 2 | First logical sector number of a copy of the three FAT32 boot sectors, typically 6.[11]
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 0x0000[11] (and/or 0xFFFF[25]) are reserved and indicate that no backup sector is available. |
0x034 | 0x29 | 12 | Reserved (may be changed to format filler byte 0xF6[nb 2] as an artifact by MS-DOS FDISK, 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 " |
0x040 | 0x35 | 1 | Cf. 0x024 for FAT12/FAT16 (Physical Drive Number) |
0x041 | 0x36 | 1 | Cf. 0x025 for FAT12/FAT16 (Used for various purposes; see FAT12/FAT16)
May hold format filler byte 0xF6[nb 2] artifacts after partitioning with MS-DOS FDISK, but not yet formatted. |
0x042 | 0x37 | 1 | Cf. 0x026 for FAT12/FAT16 (Extended boot signature, 0x29)
Most FAT32 file system implementations do not support an alternative signature of 0x28 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 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. |
0x043 | 0x38 | 4 | Cf. 0x027 for FAT12/FAT16 (Volume ID) |
0x047 | 0x3C | 11 | Cf. 0x02B for FAT12/FAT16 (Volume Label) |
0x052 | 0x47 | 8 | Cf. 0x036 for FAT12/FAT16 (File system type, padded with blanks (0x20), e.g., "FAT32␠␠␠ ")
|
Exceptions
Versions of DOS before 3.2 totally or partially relied on the media descriptor byte in the BPB or the FAT ID byte in cluster 0 of the first FAT in order to determine FAT12 diskette formats even if a BPB is present. Depending on the FAT ID found and the drive type detected they default to use one of the following BPB prototypes instead of using the values actually stored in the BPB.[nb 3]
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,[14] 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.
FAT ID (compare with media ID at BPB offset 0x0A)[27][28] | 0xFF | 0xFE | 0xFD | 0xFC | 0xFB | 0xFA | 0xF9 | 0xF8 | 0xF0 | 0xED | 0xE5 | ||||||||||
Size | 8" | 5.25" | 8" | 8" | 5.25" | 8" | 8" | 5.25" | 5.25" | 5.25" / 3.5" | 5.25" / 3.5" | 5.25" | 3.5" | 3.5" | 5.25" | 5.25" / 3.5" | 3.5" | 3.5" | 3.5" | 5.25" | 8" |
Density | ? | DD 48tpi | SD | DD | DD 48tpi | ? | SD | DD 48tpi | DD 48tpi | ? | ? | HD 96tpi | DD 135tpi | HD 135tpi | QD 96tpi | ? | DD | HD 135tpi | ED | QD 96tpi | SD |
Modulation | ? | MFM | FM | MFM | MFM | ? | FM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | MFM | FM |
Formatted capacity (KiB) | ? | 320 | 250 | 1200 | 160 | ? | 500 | 360 | 180 | 640 | 320 | 1200 | 720 | 1440 | 720 | 360 | 360 | 1440 | 2880 | 720 | 243 / 250 |
Cylinders (CHS) | 77 | 40 | 77 | 77 | 40 | 77 | 77 | 40 | 40 | 80 | 80 | 80 | 80 | 80 | 80 | 80 | 80 | 80 | 80 | 80 | 77 |
Physical sectors / track (BPB offset 0x0D) | ? | 8 | 26 | 8 | 8 | ? | 26 | 9 | 9 | 8 | 8 | 15 | 9 | 18 | 9 (8[32]) | 9 | 9 | 18 | 36 | 9 (8[32]) | 26 |
Number of heads (BPB offset 0x0F) | ? | 2 | 1 | 2[14][27] (1) | 1 | ? | 2[27] (1?[14]) | 2 | 1 | 2 | 1 | 2 | 2 | 2 | 2 | 1 | 1 | 2 | 2 | 2 | 1 |
Byte payload / physical sector | ? | 512 | 128 | 1024 | 512 | ? | 128 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 128 |
Bytes / logical sector (BPB offset 0x00) | ? | 512 | 128 | 1024 | 512 | ? | 128 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 128 |
Logical sectors / cluster (BPB offset 0x02) | ? | 2 | 4 | 1 | 1 | ? | 4 | 2 | 1 | 2 | 1[27] (2?[14]) | 1 | 2 | 1 | ? | 2 | ? | 1 | 2 | ? | 4 |
Reserved logical sectors (BPB offset 0x03) | ? | 1 | 1 | 1 | 1 | ? | 4 | 1 | 1 | 1 | 1 | 1 | 1 (2) | 1 | 1 | 1 | 1 | 1 | 1 | ? | 1 |
Number of FATs (BPB offset 0x05) | ? | 2 | 2 | 2 | 2 | ? | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
Root directory entries (BPB offset 0x06) | ? | 112 (7 sectors) | 68 (17 sectors) | 192 (6 sectors) | 64 (4 sectors) | ? | 68 (17 sectors) | 112 (7 sectors) | 64 (4 sectors) | 112 (7 sectors) | 112 (7 sectors) | 224 (14 sectors) | 112 (7 sectors) | 224 (14 sectors) | ? | 112 (7 sectors) | ? | 224 (14 sectors) | 240 (15 sectors) | ? | 64 (16 sectors) |
Total logical sectors (BPB offset 0x08) | ? | 640 | 2002 | 1232[27] (616[14]) | 320 | ? | 4004[27] (2002?[14]) | 720 | 360 | 1280 | 640 | 2400 | 1440 | 2880 | ? | 720 | ? | 2880 | 5760 | ? | 2002 |
Logical sectors / FAT (BPB offset 0x0B) | ? | 1 | 6 | 2 | 1 | ? | 6?[27] | 2 | 2 | 2 | 2[27] (1?[14]) | 7 | 3 | 9 (7) | ? | 2 | ? | 9 | 9 | ? | 1 |
Hidden sectors (BPB offset 0x11) | ? | 0 | 3[27] (0[14]) | 0 | 0 | ? | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | ? | 0 |
Total number of clusters | ? | 315 | 497 | 1227 | 313 | ? | 997?[27] | 354 | 351 | ? | ? | 2371 | 713 | 2847? | ? | ? | ? | 2847 | 2863 | ? | ? |
Logical sector order | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
Sector mapping | ? | sector+/ head+/ track+ | sector+/ track+ | sector+/ head+/ track+ | sector+/ track+ | ? | sector+/ head+/ track+ | sector+/ head+/ track+ | sector+/ track+ | sector+/ head+/ track+ | sector+/ track+ | sector+/ head+/ track+ | sector+/ head+/ track+ | sector+/ head+/ track+ | ? | sector+/ track+ | sector+/ track+ | sector+/ head+/ track+ | sector+/ head+/ track+ | ? | sector+/ track+ |
First physical sector (CHS) | ? | 1 | 1 | 1 | 1 | ? | 1 | 1 | 1 | ? | ? | 1 | 1 | 1 | ? | 1 | ? | 1 | 1 | ? | 1 |
DRIVER.SYS /F:n | ? | 0 | 3 | 4 | 0 | ? | 3 | 0 | 0 | ? | ? | 1 | 2 | 7 | ? | ? | ? | 7 | 9 | ? | 3 |
BPB Presence | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | Yes | Yes | Yes | ? | ? | ? | Yes | Yes | ? | ? |
Support | ? | DOS 1.1 | DOS 1.0 | DOS 2.0 | DOS 1.0 | ? | DOS 2.0 | DOS 2.0 | DOS 2.0 | ? | ? | DOS 3.0 | DOS 3.2 | DOS 3.2 only; (DR-DOS) | Sanyo 55x DS-DOS 2.11 only | MS-DOS 3.1[14] | MSX-DOS | DOS 3.3 | DOS 5.0 | Tandy 2000 only | DR-DOS only |
Microsoft recommends to distinguish between the two 8-inch formats for FAT ID 0xFE by trying to read of a single-density address mark. If this results in an error, the medium must be double-density.[28]
The table does not list a number of incompatible 8-inch and 5.25-inch FAT12 floppy formats supported by 86-DOS, which differ either in the size of the directory entries (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 KiB FAT12 format used in MS-DOS for the Apricot PC and F1e[34] 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 0x00B-0x017 in the standard boot sector) were located at offset 0x050. The Portable, F1, PC duo and Xi FD supported a non-standard double-sided 720 KiB FAT12 format instead.[34] 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 KiB: 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: 0xFC, logical sectors per FAT: 2, physical sectors per track: 9, number of heads: 1.[34][35]
- 720 KiB: 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: 0xFE, logical sectors per FAT: 3, physical sectors per track: 9, number of heads: 2.[34]
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 KiB data disks omitted a boot sector and began with a single copy of the FAT.[35] The first byte of the relocated FAT in logical sector 0 was used to determine the disk's capacity. 640 KiB boot disks began with a miniature ADFS file system containing the boot loader, followed by a single FAT.[35][36] Also, the 640 KiB 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).[36] 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 KiB: Bytes per logical sector: 1024 bytes, logical sectors per cluster: 1, reserved logical sectors: 0, number of FATs: 1, root directory entries: 192, total logical sectors: 800, FAT ID: 0xFD, logical sectors per FAT: 2, physical sectors per track: 5, number of heads: 2.[35][36]
- 640 KiB: Bytes per logical sector: 256 bytes, logical sectors per cluster: 8, reserved logical sectors: 16, number of FATs: 1, root directory entries: 112, total logical sectors: 2560, FAT ID: 0xFF, logical sectors per FAT: 2, physical sectors per track: 16, number of heads: 2.[35][36]
DOS Plus for the Master 512 could also access standard PC disks formatted to 180 KiB or 360 KiB, using the first byte of the FAT in logical sector 1 to determine the capacity.
FS Information Sector
The "FS Information Sector" was introduced in FAT32[37] 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 0x030 (usually logical sector 1, immediately after the boot record itself).
Byte Offset | Length (bytes) | Description |
---|---|---|
0x000 | 4 | FS information sector signature (0x52 0x52 0x61 0x41 = "RRaA ")
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 cluster 0 and cluster 1 to follow certain bit patterns, which are not met by this signature. |
0x004 | 480 | Reserved (byte values should be set to 0x00 during format, but not be relied upon and never changed later on) |
0x1E4 | 4 | FS information sector signature (0x72 0x72 0x41 0x61 = "rrAa ")
|
0x1E8 | 4 | Last known number of free data clusters on the volume, or 0xFFFFFFFF if unknown. Should be set to 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 at least smaller or equal to the volume's count of clusters. |
0x1EC | 4 | Number of the most recently known to be allocated data cluster. Should be set to 0xFFFFFFFF during format and updated by the operating system later on. With 0xFFFFFFFF the system should start at cluster 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. |
0x1F0 | 12 | Reserved (byte values should be set to 0x00 during format, but not be relied upon and never changed later on) |
0x1FC | 4 | FS information sector signature (0x00 0x00 0x55 0xAA)[11][nb 4] (All four bytes should match before the contents of this sector should be assumed to be in valid format.) |
The sector's data may be outdated and not reflect the current media contents, because not all operating systems update or use this sector, and even if they do, the contents is not valid when the medium has been ejected without properly unmounting the volume or after a power-failure. Therefore, operating systems should first inspect a volume's optional shutdown status bitflags residing in the FAT entry of cluster 1 or the FAT32 EBPB at offset 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.
If this sector is present on a FAT32 volume, the minimum allowed logical sector size is 512 bytes, whereas otherwise it would be 128 bytes. Some FAT32 implementations support a slight variation of Microsoft's specification by making the FS information sector optional by specifying a value of 0xFFFF[25] (or 0x0000) in the entry at offset 0x030.
File Allocation Table
A volume's data area is divided up 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 partition; typically cluster sizes lie somewhere between 2 KiB and 32 KiB.
Each file may occupy one or more of these clusters depending on its size; thus, a file is represented by a chain of these clusters (referred to as a singly linked list). However 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.
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 (f.e. cluster 0) and the 12 most significant bits the second (f.e 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.
Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+0000 | F0 | FF | FF | 03 | 40 | 00 | 05 | 60 | 00 | 07 | 80 | 00 | FF | AF | 00 | 14 |
+0010 | C0 | 00 | 0D | E0 | 00 | 0F | 00 | 01 | 11 | F0 | FF | 00 | F0 | FF | 15 | 60 |
+0020 | 01 | 19 | 70 | FF | F7 | AF | 01 | FF | 0F | 00 | 00 | 70 | FF | 00 | 00 | 00 |
- FAT ID / endianess marker (in reserved cluster #0), with 0xF0h indicating a volume on a non-partitioned superfloppy drive (must be 0xF8h for partitioned disks)
- End of chain indicator / maintenance flags (in reserved cluster #1)
- Second chain (7 clusters) for a non-fragmented file (here: #2, #3, #4, #5, #6, #7, #8)
- Third chain (7 clusters) for a fragmented, possibly grown file (here: #9, #A, #14, #15, #16, #19, #1A)
- Fourth chain (7 clusters) for a non-fragmented, possibly truncated file (here: #B, #C, #D, #E, #F, #10, #11)
- Empty clusters
- Fifth chain (1 cluster) for a sub-directory (here: #23)
- Bad clusters (3 clusters) (here: #27, #28, #2D)
The FAT16 file system uses 16 bits per FAT entry, thus one entry spans two bytes in little-endian byte order:
Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+0000 | F0 | FF | FF | FF | 03 | 00 | 04 | 00 | 05 | 00 | 06 | 00 | 07 | 00 | 08 | 00 |
+0010 | FF | FF | 0A | 00 | 14 | 00 | 0C | 00 | 0D | 00 | 0E | 00 | 0F | 00 | 10 | 00 |
+0020 | 11 | 00 | FF | FF | 00 | 00 | FF | FF | 15 | 00 | 16 | 00 | 19 | 00 | F7 | FF |
+0030 | F7 | FF | 1A | 00 | FF | FF | 00 | 00 | 00 | 00 | F7 | FF | 00 | 00 | 00 | 00 |
The FAT32 file system uses 32 bits per FAT entry, thus one entry spans four bytes in little-endian byte order. The four top bits of each entry are reserved for other purposes, cleared during format and should not be changed otherwise. They must be masked off before interpreting the entry as 28-bit cluster address.
Offset | +0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 | +8 | +9 | +A | +B | +C | +D | +E | +F |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
+0000 | F0 | FF | FF | 0F | FF | FF | FF | 0F | FF | FF | FF | 0F | 04 | 00 | 00 | 00 |
+0010 | 05 | 00 | 00 | 00 | 06 | 00 | 00 | 00 | 07 | 00 | 00 | 00 | 08 | 00 | 00 | 00 |
+0020 | FF | FF | FF | 0F | 0A | 00 | 00 | 00 | 14 | 00 | 00 | 00 | 0C | 00 | 00 | 00 |
+0030 | 0D | 00 | 00 | 00 | 0E | 00 | 00 | 00 | 0F | 00 | 00 | 00 | 10 | 00 | 00 | 00 |
+0040 | 11 | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 | FF | FF | FF | 0F |
+0050 | 15 | 00 | 00 | 00 | 16 | 00 | 00 | 00 | 19 | 00 | 00 | 00 | F7 | FF | FF | 0F |
+0060 | F7 | FF | FF | 0F | 1A | 00 | 00 | 00 | FF | FF | FF | 0F | 00 | 00 | 00 | 00 |
+0070 | 00 | 00 | 00 | 00 | F7 | FF | FF | 0F | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
- First chain (1 cluster) for the root directory, pointed to by an entry in the FAT32 BPB (here: #2)
- 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 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 FAT ID in the FAT's cluster 0 entry on DOS 1.0-1.1 FAT diskettes, where no valid BPB is found.
The first two entries in a FAT store special values:
The first entry (cluster 0 in the FAT) holds the FAT ID since MS-DOS 1.20 and PC DOS 1.1 (allowed values 0xF0-0xFF with 0xF1-0xF7 reserved) in bits 7-0, which is also copied into the BPB of the boot sector, offset 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. These values were arranged so that the entry would also function as an "trap-all" end-of-chain marker for all data clusters holding a value of zero. Additionally, for FAT IDs other than 0xFF (and 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. 86-DOS 0.42 up to MS-DOS 1.14 used hard-wired drive profiles instead of a FAT ID, but used this byte to distinguish between media formatted with 32-byte or 16-byte directory entries, as they were used prior to 86-DOS 0.42.
The second entry (cluster 1 in the FAT) nominally stores the end-of-cluster-chain marker as used by the formater, but typically always holds 0xFFF / 0xFFFF / 0x0FFFFFFF, that is, with the exception of bits 31-28 on FAT32 volumes these bits are normally always set. Some Microsoft operating systems, however, set these bits if the volume is not the volume holding the running operating system (that is, use 0xFFFFFFFF instead of 0x0FFFFFFF here).[38] (In conjunction with alternative end-of-chain markers the lowest bits 2-0 can become zero for the lowest allowed end-of-chain marker 0xFF8 / 0xFFF8 / 0x?FFFFFF8; bit 3 should be reserved as well given that clusters 0xFF0 / 0xFFF0 / 0x?FFFFFF0 and higher are officially reserved. 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.) For DOS 1 and 2, the entry was documented as reserved for future use.
Since DOS 7.1 the two most-significant bits of this cluster entry may hold two optional bitflags representing the current volume status on FAT16 and FAT32, but not on FAT12 volumes. These bitflags are not supported by all operating systems, but operating systems supporting this feature would set these bits on shutdown and clear the most significant bit on startup:
If bit 15 (on FAT16) or bit 27 (on FAT32)[39] 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.[29] On FAT32 volumes, the FS Information Sector may hold outdated data and thus should not be used. The operating system would then typically run SCANDISK or CHKDSK on the next startup[nb 9][39] (but not on insertion of removable media) to ensure and possibly reestablish the volume's integrity.
If bit 14 (on FAT16) or bit 26 (on FAT32)[39] is cleared, the operating system has encountered disk I/O errors on startup,[39] 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.[39][29] (A similar set of bitflags exists in the FAT12/FAT16 EBPB at offset 0x1A or the FAT32 EBPB at offset 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, 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, 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.
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,[33] and cluster 2 is by definition the first cluster in the data area.
FAT entry values:
FAT12 | FAT16 | FAT32 | Description |
---|---|---|---|
0x000 | 0x0000 | 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.[12][13]
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.[14] |
0x001 | 0x0001 | 0x?0000001 | Reserved for internal purposes; MS-DOS/PC DOS use this cluster value as a temporary non-free cluster indicator while constructing cluster chains during file allocation (only seen on disk if there is a crash or power failure in the middle of this process).[12][13]
If this value occurs in on-disk cluster chains, file system implementations should treat this like an end-of-chain marker. |
0x002 - 0xFEF | 0x0002 - 0xFFEF (0x0002 - 0x7FFF) | 0x?0000002 - 0x?FFFFFEF | Used as data clusters; value points to next cluster. MS-DOS/PC DOS accept values up to 0xFEF / 0xFFEF / 0x0FFFFFEF (sometimes more; see below), whereas for Atari GEMDOS only values up to 0x7FFF are allowed on FAT16 volumes. |
0xFF0[nb 10] - 0xFF5 (0xFF1 - 0xFF5) | 0xFFF0 - 0xFFF5 | 0x?FFFFFF0 - 0x?FFFFFF5 | Reserved in some contexts,[40] or also used[7][8][9][11][41] 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, and should avoid to allocate them for files otherwise.
MS-DOS/PC DOS 3.3 and higher treats a value of 0xFF0[nb 10] on FAT12 (but not on FAT16 or FAT32) volumes as additional end-of-chain marker similar to 0xFF8-0xFFF. For compatibility with MS-DOS/PC DOS, file systems should avoid to use data cluster 0xFF0 in cluster chains on FAT12 volumes (that is, treat it as a reserved cluster similar to 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 | 0x?FFFFFF6 | Reserved; do not use.[7][8][9][11][41][26] (NB. Corresponds with the default format filler value 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.[14] |
0xFF7 | 0xFFF7 | 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 (0xFF5 and 0xFFF5, respectively) will always be smaller than this value. Therefore, this value cannot normally occur in cluster-chains, but if it does, it may be treated as a normal data cluster, since 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,[14] and 0xFFF7 could have been a non-standard data cluster on FAT16 volumes before the introduction of FAT32 with DOS 7.10. Theoretically, 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.[14] Disk utilities must not attempt to restore "lost clusters" holding this value in the FAT, but count them as bad clusters. |
0xFF8 - 0xFFF (and optionally 0xFF0;[nb 10] see note) | 0xFFF8 - 0xFFFF | 0x?FFFFFF8 - 0x?FFFFFFF | Last cluster in file (EOC). File system implementations must treat all these values as end-of-chain marker at the same time.[14] Most file system implementations (including 86-DOS, MS-DOS, PC DOS and DR-DOS) use 0xFFF[14] / 0xFFFF[14] / 0x0FFFFFFF as end-of-file marker when allocating files, but versions of Linux before 2.5.40 used 0xFF8 / 0xFFF8 / 0x0FFFFFF8.[42] Versions of mkdosfs (dosfstools up to 3.0.26) continue to use 0x0FFFFFF8 for the root directory on FAT32 volumes, whereas some disk repair and defragment tools utilize other values in the set (e.g., SCANDISK may use 0xFF8 / 0xFFF8 / 0x0FFFFFF8 instead). While in the original 8-bit FAT implementation in Microsoft's Standalone Disk BASIC different end markers (0xC0..0xCD) were used to indicate the number of sectors (0 to 13) used up in the last cluster occupied by a file, different end markers were repurposed under DOS to indicate different types of media,[14] with the currently used end marker indicated in the cluster 1 entry, however, this concept does not seem to have been broadly utilized in practice—and to the extent that in some scenarios volumes may not be recognized by some operating systems, if some of the low-order bits of the value stored in cluster 1 are not set. Also, some faulty file system implementations only accept 0xFFF / 0xFFFF / 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 FAT ID and media descriptor values;[14] see note above for MS-DOS/PC DOS special usage of 0xFF0[nb 10] on FAT12 volumes.) |
Despite its name FAT32 uses only 28 bits of the 32 possible bits. The upper 4 bits 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.
Directory table
A directory table is a special type of file that represents a directory (also known as a folder). Since 86-DOS 0.42,[43] each file or (since MS-DOS 1.40 and PC 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, directory, hidden, read-only, system and volume), the address of the first cluster of the file/directory's data, the size of the file/directory, and the date[43] and (since PC 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 MiB and no time of last modification.[43]
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.
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 DOS limits the absolute path of a directory to 66 characters (including the drive letter, but excluding the NUL byte delimiter),[7][8][9] thereby limiting the maximum supported depth of subdirectories to 32, whatever occurs earlier. Concurrent DOS, Multiuser DOS and DR DOS 3.31 to 6.0 (up to including the 1992-11 updates) do not store absolute paths to working directories internally and therefore do not show this limitation.[44] The same applies to Atari GEMDOS, but the Atari Desktop does not support more than 8 sub-directory levels. Most applications aware of this extension support paths up to at least 127 bytes. FlexOS, 4680 OS and 4690 OS support a length of up to 127 bytes as well, allowing depths down to 60 levels.[45] PalmDOS, DR DOS 6.0 (since BDOS 7.1) and higher, Novell DOS, and OpenDOS sport a MS-DOS-compatible CDS and therefore have the same length limits as MS-DOS/PC DOS.
Note that before each entry there can be "fake entries" to support a VFAT long filename (LFN); see further below.
Legal characters for DOS short filenames include the following:
- Upper case letters
A
–Z
- Numbers
0
–9
- 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 95 because of the lack of a suitable escaping system). Another exception are the internal commands
MKDIR
/MD
andRMDIR
/RD
under DR-DOS which accept single arguments and therefore allow spaces to be entered.
! # $ % & ' ( ) - @ ^ _ ` { } ~
- Characters 128–255
This excludes the following ASCII characters:
" * / : < > ? \ |
Windows/MS-DOS has no shell escape character+ , . ; = [ ]
Allowed in long file names only- Lower case letters
a
–z
Stored asA
–Z
; allowed in long file names - Control characters 0–31
- Character 127 (DEL)
The following additional characters are allowed on Atari's GEMDOS, but should be avoided for compatibility with MS-DOS/PC DOS:
" + , ; < = > [ ] |
The semicolon (;
) should be avoided in filenames under DR DOS 3.31 and higher, PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, System Manager and REAL/32, because it may conflict with the syntax to specify file and directory passwords: "...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD
". The operating system will strip off one[44] (and also two—since DR-DOS 7.02) semicolons and pending passwords from the 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.[44])
The at-sign character (@
) is used for filelists by many DR-DOS, PalmDOS, Novell DOS, OpenDOS and Multiuser DOS, System Manager and REAL/32 commands, as well as by 4DOS and may therefore sometimes be difficult to use in filenames.[44]
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.[44]
Under IBM 4680 OS and 4690 OS, the following characters are not allowed in filenames:
? * : . ; , [ ] ! + = < > " - / \ |
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:
@ # ( ) { } $ &
The DOS file names are in the current 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 CHCP) with respect to lower and upper case, sorting, or validity as file name character.
Directory entry
Before Microsoft added support for long filenames and creation/access time stamps, bytes 0x0C–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).
32-byte directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3 filename):
Byte Offset | Length (bytes) | Description | ||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0x00 | 8 | Short file name (padded with spaces)
The first byte can have the following special values:
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. | ||||||||||||||||||||||||||||||||||||||||||
0x08 | 3 | Short file extension (padded with spaces) | ||||||||||||||||||||||||||||||||||||||||||
0x0B | 1 | File Attributes
Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, the volume attribute is set for pending delete files and directories under DELWATCH. An attribute combination of 0x0F is used to designate a VFAT long file name entry since MS-DOS 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 " | ||||||||||||||||||||||||||||||||||||||||||
0x0C | 1 |
FAT32.IFS is critically conflictive with FAT32+ revision 2. | ||||||||||||||||||||||||||||||||||||||||||
0x0D | 1 |
Double usage for create time ms and file char is not conflictive, since the creation time is no longer important for deleted files. | ||||||||||||||||||||||||||||||||||||||||||
0x0E | 2 |
If bits 15-11 > 23 or bits 10-5 > 59 or bits 4-0 > 29 here, or when bits 12-0 at offset 0x14 hold an access bitmap and this is not a FAT32 volume or a volume using OS/2 Extended Attributes, then this entry actually holds a password hash, otherwise it can be assumed to be a file creation time. | ||||||||||||||||||||||||||||||||||||||||||
0x10 | 2 |
The usage for creation date for existing files and last modified time for deleted files is not conflictive 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 is not conflictive as well. 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. To avoid the conflict, the storage of creation dates should be an optional feature of operating systems supporting it. | ||||||||||||||||||||||||||||||||||||||||||
0x12 | 2 |
The usage for the owner IDs of existing files and last modified date stamp for deleted files is not conflictive because they are never used at the same time.[44] The usage of the last modified date stamp for deleted files and access date is also not conflictive since access dates are no longer important for deleted files, however, owner IDs and access dates cannot be used at the same time. | ||||||||||||||||||||||||||||||||||||||||||
0x14 | 2 |
The storage of the high two bytes of the first cluster in a file on FAT32 is partially conflictive with access rights bitmaps. | ||||||||||||||||||||||||||||||||||||||||||
0x16 | 2 |
| ||||||||||||||||||||||||||||||||||||||||||
0x18 | 2 |
| ||||||||||||||||||||||||||||||||||||||||||
0x1A | 2 | 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 0x14.
Entries with the Volume Label flag, subdirectory ".." pointing to FAT12/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. | ||||||||||||||||||||||||||||||||||||||||||
0x1C | 4 | 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 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. For files larger than 4 GiB following the FAT+ proposal, this entry only holds the size of the last chunk of the file (that is bits 31-0). The most significant bits 37-32 are stored in the entry at offset 0x0C.[2] |
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:[55]
- Local: Don't distributed file but keep on local controller only.[nb 12]
- 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.[56]
Some incompatible extensions found in some operating systems include:
Byte Offset | Length (bytes) | System | Description |
---|---|---|---|
0x0C | 2 | RISC OS | File type, 0x0000–0x0FFF |
0x0C | 4 | Petrov DOSFS | File load address |
0x0E | 2 | ANDOS | File address in the memory |
0x10 | 4 | Petrov DOSFS | File execution address |
VFAT long file names
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/VFAT_directory_entries.png/350px-VFAT_directory_entries.png)
VFAT Long File Names (LFN) are stored on a FAT file system using a trick—adding (possibly multiple) 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 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 DOS 6.0 (1991) and higher. It is also similar to a method publically discussed to store long filenames on Ataris and under Linux in 1992.[57][58]
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).[nb 11]
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.[48]
After the last UCS-2 character, a 0x0000 is added. The remaining unused characters are filled with 0xFFFF.
LFN entries use the following format:
Byte Offset | Length (bytes) | Description |
---|---|---|
0x00 | 1 | Sequence Number (bit 6: last logical, first physical LFN entry, bit 5: 0; bits 4-0: number 0x01..0x14 (0x1F), deleted entry: 0xE5) |
0x01 | 10 | Name characters (five UCS-2 characters) |
0x0B | 1 | Attributes (always 0x0F) |
0x0C | 1 | Type (always 0x00 for VFAT LFN, other values reserved for future use; for special usage of bits 4 and 3 in SFNs see below) |
0x0D | 1 | Checksum of DOS file name |
0x0E | 12 | Name characters (six UCS-2 characters) |
0x1A | 2 | First cluster (always 0x0000) |
0x1C | 4 | Name characters (two UCS-2 characters) |
If there are multiple LFN entries, required to represent a file name, firstly comes the last LFN entry (the last part of the filename). The sequence number also has bit 6 (0x40) set (this means the last LFN entry, however it's the first entry seen when reading the directory file). The last LFN entry has the largest sequence number which decreases in following entries. The first LFN entry has sequence number 1. A value of 0xE5 is used to indicate that the entry is deleted.
On FAT12 and FAT16 volumes, testing for the values at 0x1A to be zero and at 0x1C to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH.
For example a filename like "File with very long filename.ext" would be formatted like this:
Sequence number | Entry data |
---|---|
0x43 | "me.ext" |
0x02 | "y long filena" |
0x01 | "File with ver" |
??? | 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. (Note that 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 0x20). For example, "Readme.txt" would be "README␠␠TXT
".)
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;
}
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 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 "example.TXT
" or "HELLO.txt
" but not "Mixed.txt
". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (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 /fs/fat/dir.c
and fs/vfat/namei.c
); the mount option shortname
determines whether this feature is used when writing.[59]
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:
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 KiB) FAT32 minimum : 1 sector per cluster × 65,525 clusters = 33,548,800 bytes (32,762.5 KiB) FAT12 maximum : 64 sectors per cluster × 4,084 clusters = 133,824,512 bytes (≈ 127 MiB) [FAT12 maximum : 128 sectors per cluster × 4,084 clusters = 267,694,024 bytes (≈ 255 MiB)] FAT16 maximum : 64 sectors per cluster × 65,524 clusters = 2,147,090,432 bytes (≈2,047 MiB) [FAT16 maximum : 128 sectors per cluster × 65,524 clusters = 4,294,180,864 bytes (≈4,095 MiB)] FAT32 maximum : 8 sectors per cluster × 268,435,444 clusters = 1,099,511,578,624 bytes (≈1,024 GiB) FAT32 maximum : 16 sectors per cluster × 268,173,557 clusters = 2,196,877,778,944 bytes (≈2,046 GiB) [FAT32 maximum : 32 sectors per cluster × 134,152,181 clusters = 2,197,949,333,504 bytes (≈2,047 GiB)] [FAT32 maximum : 64 sectors per cluster × 67,092,469 clusters = 2,198,486,024,192 bytes (≈2,047 GiB)] [FAT32 maximum : 128 sectors per cluster × 33,550,325 clusters = 2,198,754,099,200 bytes (≈2,047 GiB)]
- Legend: 268435444+3 is 0x0FFFFFF7, because FAT32 version 0 uses only 28 bits in the 32-bit cluster numbers, cluster numbers 0x0FFFFFF7 up to 0x0FFFFFFF flag bad clusters or the end of a file, cluster number 0 flags a free cluster, and cluster number 1 is not used.[33] Likewise 65524+3 is 0xFFF7 for FAT16, and 4084+3 is 0xFF7 for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 (0x01), the biggest value is 128 (0x80). Lines in square brackets indicate the unusual cluster size 128, and for FAT32 the bigger than necessary cluster sizes 32 or 64.[60]
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 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 (0x28) or 41 (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 straight forward, each entry occupies 32 bytes, this results in 16 entries per sector for a sector size of 512 bytes. The DOS 5 RMDIR
/RD
command removes the initial ".
" (this directory) and "..
" (parent directory) entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12, but requires 2 or more sectors per cluster. A FAT12 boot sector without the DOS 4 extensions needs 29 bytes before the first unnecessary FAT16B 32-bit number of hidden sectors, this leaves three bytes for the (on a RAM disk unused) boot code and the magic 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 FORMAT command options /A:128K
and /A:256K
correspond to the maximal cluster size 0x80
(128) with a sector size 1024 and 2048, respectively. For the common sector size 512 /A:64K
yields 128 sectors per cluster.
Both editions of each ECMA-107[7] and ISO/IEC 9293[8][9] specify a Max Cluster Number MAX
determined by the formula MAX=1+trunc((TS-SSA)/SC)
, and reserve cluster numbers MAX+1
up to 4086 (0xFF6, FAT12) and later 65526 (0xFFF6, FAT16) for future standardization.
Microsoft's EFI FAT32 specification[11] states that any FAT file system with less than 4085 clusters is FAT12, else any FAT file system with less than 65525 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 (0xFFF, 0xFFFF or 0x0FFFFFFF). The entries for cluster numbers 0 and 1 end at a byte boundary even for FAT12, e.g., 0xF9FFFF for media descriptor 0xF9.
The first data cluster is 2,[33] and consequently the last cluster MAX
gets number MAX+1
. This results in data cluster numbers 2...4085 (0xFF5) for FAT12, 2...65525 (0xFFF5) for FAT16, and 2...268435445 (0x0FFFFFF5) for FAT32.
The only available values reserved for future standardization are therefore 0xFF6 (FAT12) and 0xFFF6 (FAT16). As noted below "less than 4085" is also used for Linux implementations,[41] or as Microsoft's FAT specification puts it:[11]
when it says <, it does not mean <=. Note also that the numbers are correct. The first number for FAT12 is 4085; the second number for FAT16 is 65525. These numbers and the ‘<’ signs are not wrong.
Fragmentation
The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition.[61] On volumes where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time.
While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (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., HPFS or exFAT, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (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 KiB 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 for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "DIR
" operation, which always displays the free disk space as the last line.[62] Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special file system information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-ATX-style PCs, on plain DOS systems and some battery-powered consumer products.
With the huge cluster sizes (16 KiB, 32 KiB, 64 KiB) 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 inherit design without having to change the layout of the on-disk structures. They can be divided into on-line and off-line methods and work by trying to avoid fragmentation in the file system in the first place, deploying methods to better cope with existing fragmentation, and by reordering and optimizing the on-disk structures. With optimizations in place, the performance on FAT volumes can often reach that of more sophisticated file systems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.
DOS 3.0 and higher will not immediately reuse disk space of deleted files for new allocations but instead seek for previously unused space before starting to use disk space of previously deleted files as well. This not only helps to maintain the integrity of deleted files for as long as possible but also speeds up file allocations and avoids fragmentation, since never before allocated disk space is always unfragmented. DOS accomplishes this by keeping a pointer to the last allocated cluster on each mounted volume in memory and starts searching for free space from this location upwards instead of at the beginning of the FAT, as it was still done by DOS 2.x.[20] 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.[20] These pointers are initialized to point to the start of the FATs after bootup,[20] but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the FS Information Sector. This mechanism is defeated, however, if an application often deletes and recreates temporary files as the operating system would then try to maintain the integrity of void data effectively causing more fragmentation in the end.[20] 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 0xE5 since DOS 3.0.[12] 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.[13]
Since DOS 3.3 the operating system provides means to improve the performance of file operations with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC DOS) or hash tables (DR-DOS), which can reduce file seek and open times significantly. Before DOS 5.0 special care must be taken when using such mechanisms in conjunction with disk defragmentation software bypassing the file system or disk drivers.
Windows NT will allocate disk space to files on FAT in advance, selecting large contiguous areas, but in case of a failure, files which were being appended will appear larger than they were ever written into, with a lot of random data at the end.
Other high-level mechanisms may read in and process larger parts or the complete FAT on startup or on demand when needed and dynamically build up in-memory tree representations of the volume's file structures different from the on-disk structures. This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background.
Some of the perceived problems with fragmentation of FAT file systems also result from performance limitations of the underlying block device drivers, which becomes more visible the lesser memory is available for sector buffering and track blocking/deblocking:
While the single-tasking DOS had provisions for multi-sector reads and track blocking/deblocking, the operating system and the traditional PC hard disk architecture (only one outstanding input/output request at a time and 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 EMS or XMS memory and sometimes providing adaptive caching strategies or even run in protected mode through DPMS or Cloaking to increase performance by gaining direct access to the cached data in linear memory rather than through conventional DOS APIs.
Write-behind caching was often not enabled by default with Microsoft software (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.
Patents
Microsoft applied for, and was granted, a series of patents for key parts of the FAT file system in the mid-1990s. All four pertain to long-filename extensions to FAT first seen in Windows 95: U.S. patent 5,579,517, U.S. patent 5,745,902, U.S. patent 5,758,352, U.S. patent 6,286,013.
On December 3, 2003 Microsoft announced[63] that it would be offering licenses for use of its FAT specification and "associated intellectual property", at the cost of a US$0.25 royalty per unit sold, with a $250,000 maximum royalty per license agreement.[64] To this end, Microsoft cited four patents on the FAT file system as the basis of its intellectual property claims.
In the EFI FAT32 specification[11] Microsoft specifically grants a number of rights, which many readers have interpreted as permitting operating system vendors to implement FAT.[65]
Non-Microsoft patents affecting FAT include: U.S. patent 5,367,671, specific to the OS/2 extended object attributes (expired in 2011).
Challenges and lawsuits
The Public Patent Foundation (PUBPAT) submitted evidence to the US Patent and Trade Office (USPTO) in 2004 disputing the validity of U.S. patent 5,579,517, including prior art references from Xerox and IBM.[66] The USPTO opened an investigation and concluded by rejecting all claims.[67] The next year, the USPTO further announced that following the re-examination process, it affirmed the rejection of '517 and additionally found U.S. patent 5,758,352 invalid on the grounds that the patent had incorrect assignees.
However, in 2006 the USPTO ruled that features of Microsoft's implementation of the FAT system were "novel and non-obvious", reversing both earlier decisions and leaving the patents valid.[68]
In February 2009, Microsoft filed a patent infringement lawsuit against TomTom alleging that the device maker's products infringe on patents related to VFAT long filenames. As some TomTom products are based on Linux, this marked the first time that Microsoft tried to enforce its patents against the Linux platform.[69] The lawsuit was settled out of court the following month with an agreement that Microsoft be given access to four of TomTom's patents, that TomTom will drop support for the VFAT long filenames from its products, and that in return Microsoft not seek legal action against TomTom for the five year duration of the settlement agreement.[70]
In October 2010, Microsoft filed a patent infringement lawsuit against Motorola alleging several patents (including two of the VFAT patents) were not licensed for use in the Android operating system.[71] They also submitted a complaint to the ITC.[72] Developers of open source software have designed methods intended to circumvent Microsoft's patents.[73][74]
In 2013, patent EP0618540 "common name space for long and short filenames" was invalidated in Germany.[75]
See also
- Comparison of file systems
- Drive letter assignment
- List of file systems
- Transaction-Safe FAT File System
Notes
- ^ a b This is the reason, why 0xE5 had a special meaning in directory entries.
- ^ a b c One utility providing an option to specify the desired format filler value for hard disks is DR-DOS' FDISK R2.31 with its optional wipe parameter
/W:246
. 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. - ^ a b c For maximum compatibility with MS-DOS/PC DOS and DR-DOS, operating systems trying to determine a floppy disk's format should test on all mentioned opcode sequences at sector offset 0x000 in addition to looking for a valid media descriptor byte at sector offset 0x015 before assuming the presence of a BPB. Although PC DOS 1.0 floppy disks do not contain a BPB, they start with 0xEB as well, but do not show a 0x90 at offset 0x002. PC DOS 1.10 floppy disks even start with 0xEB 0x?? 0x90, although they still do not feature a BPB. In both cases, a test for a valid media descriptor at offset 0x015 would fail (value 0x00 instead of valid media descriptors 0xF0 and higher). If these tests fail, DOS checks for the presence of a media descriptor byte in the first byte of the first FAT in the sector following the boot sector (logical sector 1 on FAT12/FAT16 floppies).
- ^ a b c d e The signature at offset 0x1FE in boot sectors is 0x55 0xAA, that is 0x55 at offset 0x1FE and 0xAA at offset 0x1FF. Since little-endian representation must be assumed in the context of IBM PC compatible machines, this can be written as 16-bit word 0xAA55 in programs for x86 processors (note the swapped order), whereas it would have to be written as 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, this article uses the offset-based byte-wise on-disk representation to avoid any possible misinterpretation.
- ^ a b c The checksum entry in Atari boot sectors holds the alignment value, not the magic value itself. The magic value 0x1234 is not stored anywhere on disk. In contrast to Intel x86 processors, the 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.
- ^ a b The following DOS functions return these register values: INT 21h/AH=2Ah "Get system date" returned values: CX = year (1980..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).
- ^ 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.)
- ^ In order to support the coexistance of DR-DOS with PC DOS and multiple parallel installations of DR-DOS, the extension of the default "
IBMBIO␠␠COM
" boot file name can be changed using theSYS /DR:ext
option, where ext represents the new extension. Other potential DR-DOS boot file names to be expected in special scenarios are "DRBIOS␠␠SYS
", "DRDOS␠␠␠SYS
", "IO␠␠␠␠␠␠SYS
", "JO␠␠␠␠␠␠SYS
". - ^ 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.
- ^ a b c d See other links for special precautions in regard to occurrences of a cluster value of 0xFF0 on FAT12 volumes under MS-DOS/PC DOS 3.3 and higher.
- ^ a b To avoid potential misinterpretation of directory volume labels with VFAT LFN entries by non-VFAT aware operating systems, the DR-DOS 7.07 FDISK and FORMAT tools are known to explicitly write dummy "
NO␠NAME␠␠␠␠
" 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. - ^ This IBM 4680 OS and 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.
References
- ^ "File Systems". Microsoft TechNet. 2001. Retrieved 2011-07-31.
- ^ a b c d e f g Udo Kuhnt, Luchezar Georgiev, Jeremy Davis (2007). FAT+. FATPLUS.TXT, draft revision 2 ([1], [2]).
- ^ a b Microsoft (2006-11-15). Windows 95 CD-ROM CONFIG.TXT File 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:
ACCDATE=drive1+|- [drive2+|-]...
" - ^ a b "FAT File System (Windows Embedded CE 6.0)". Microsoft. 2010-01-06. Retrieved 2013-07-07.
- ^ "Comparing NTFS and FAT file systems". Microsoft. Retrieved 2014-01-27.
- ^ a b JEIDA/JEITA/CIPA (2010). "Standard of the Camera & Imaging Products Association, CIPA DC-009-Translation-2010, Design rule for Camera File system: DCF Version 2.0 (Edition 2010)" (PDF). Retrieved 2011-04-13.
- ^ a b c d e f g h i j k "Volume and File Structure of Disk Cartridges for Information Interchange". Standard ECMA-107 (2nd ed., June 1995). ECMA. 1995. Retrieved 2011-07-30.
- ^ a b c d e f g h i j k "Information technology -- Volume and file structure of disk cartridges for information interchange". ISO/IEC 9293:1994. ISO catalogue. 1994. Retrieved 2012-01-06.
- ^ a b c d e f g h i j k "Information processing -- Volume and file structure of flexible disk cartridges for information interchange". ISO 9293:1987. ISO catalogue. 1987. Retrieved 2012-01-06.
- ^ Aaron R. Reynolds, Dennis R. Adler, Ralph A. Lipe, Ray D. Pedrizetti, Jeffrey T. Parsons, Rasipuram V. Arun (1998-05-26). "Common name space for long and short filenames". US Patent 5758352. Retrieved 2012-01-19.
{{cite web}}
: CS1 maint: multiple names: authors list (link) - ^ a b c d e f g h i j k l m n o p "Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format". Microsoft. 2000-12-06. Retrieved 2011-07-03.
- ^ a b c d e Schulman, Andrew; Brown, Ralf; Maxey, David; Michels, Raymond J.; Kyle, Jim (1994). 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 (2 ed.). Addison Wesley. p. 11. ISBN 0-201-63287-X. ISBN 978-0-201-63287-3.
- ^ a b c d e f Geoff Chappell (1994). DOS Internals. Addison Wesley. ISBN 0-201-60835-9, ISBN 978-0-201-60835-9.
- ^ a b c d e f g h i j k l m n o p q r s t u v w Microsoft MS-DOS 3.1 Programmierhandbuch in englischer Sprache. München: Markt & Technik Verlag (published 1986). 1984. ISBN 3-89090-368-1. 8411-310-02, 036-014-012.
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 (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."
{{cite book}}
: Unknown parameter|trans_title=
ignored (|trans-title=
suggested) (help) (NB. This book contains many errors.) - ^ a b Daniel B. Sedory. The Boot Sector of IBM® Personal Computer™ DOS Version 1.00 (1981). 2005-08-02 ([3]).
- ^ a b Daniel B. Sedory. The Boot Sector of IBM® Personal Computer™ DOS Version 1.10 (1982). 2005-07-29 ([4]).
- ^ 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 0x69 as well.
- ^ Matthias Paul (2002-02-20). "Need DOS 6.22 (Not OEM)". alt.msdos.programmer. Retrieved 2006-10-14.
- ^ Wally Bass (1994-02-14). "Cluster Size". comp.os.msdos.programmer. Retrieved 2006-10-14.
- ^ a b c d e f g h Dave Williams (1992). Programmer's Technical Reference for MSDOS and the IBM PC. DOSREF, Shareware version 01/12/1992. ISBN 1-878830-02-3. ([5], 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).
- ^ Matthias Paul (2004-08-25). "NOVOLTRK.REG". www.drdos.org. Retrieved 2011-12-17.
- ^ IBM (1983). IBM PC Technical Reference Handbook. Comment: Includes a complete listing of the ROM BIOS source code of the original IBM PC.
- ^ a b c d 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.
- ^ Seagate Technologies, "The Transition to Advanced Format 4K Sector Hard Drives", 2010 ([6]).
- ^ a b c d Ralf Brown (2002-12-29). "The x86 Interrupt List". Retrieved 2011-10-14.
- ^ a b c Microsoft MS-DOS Programmer's Reference: version 5.0. Microsoft press. 1991. ISBN 1-55615-329-5.
- ^ a b c d e f g h i j k "Standard Floppy Disk Formats Supported by MS-DOS". Microsoft Help and Support. 2003-05-12. Retrieved 2012-09-11.
- ^ a b c Microsoft (1987-07). MS-DOS 3.3 Programmer's Reference.
- ^ a b c Andries Brouwer (2002-09-20). "The FAT file system". Retrieved 2011-10-16.
- ^ a b c d e f g h i j Ray Duncan (1988). The MS-DOS Encyclopedia - version 1.0 through 3.2. Microsoft Press. ISBN 1-55615-049-0.
- ^ a b "Detailed Explanation of FAT Boot Sector". Microsoft Knowledge Base. 2003-12-06. Retrieved 2011-10-16.
- ^ a b c Lai, Robert S.; The Waite Group (1987). Writing MS-DOS Device Drivers (2nd ed.). Addison Wesley. ISBN 0-201-60837-5.
- ^ a b c d Tim Paterson (1983). "An Inside Look at MS-DOS". Byte. Retrieved 2011-07-18.
The numbering starts with 2; the first two numbers, 0 and 1, are reserved.
- ^ a b c d PORT-DOS - Userprompt Guide for Apricot Portable. User-Prompt Guides, UK ([7]).
- ^ a b c d e John Elliott (1998). DOSPLUS disc formats. ([8]).
- ^ a b c d The BBC Master 512. Yellow Pig's BBC Computer Pages ([9]).
- ^ "Detailed Explanation of FAT Boot Sector". DEW Associates Corporation. 2002. Retrieved 2011-10-16.
- ^ Daniel B. Sedory. Detailed Notes on the "Dirty Shutdown Flag" under MS-Windows. 2001-12-04. ([10]).
- ^ a b c d e "Windows 98 Resource Kit - Chapter 10 - Disks and File Systems". Microsoft TechNet. 1998. Retrieved 2012-07-16.
- ^ Peter Norton (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157.
- ^ a b c Andries Brouwer. "FAT under Linux".
- ^ Andries Brouwer (2002-09-20). "FAT". Retrieved 2012-01-11.
- ^ a b c Seattle Computer Products (1981). "SCP 86-DOS 1.0 Addendum" (PDF). Retrieved 2013-03-10.
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak Matthias Paul (1997-07-30). NWDOS-TIPs — Tips & Tricks rund um Novell DOS 7, mit Blick auf undokumentierte Details, Bugs und Workarounds (e-book) (in German) (edition 3, release 157 ed.). Retrieved 2012-01-11.
{{cite book}}
:|work=
ignored (help) 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 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 NWDOSTIP.TXT file. - ^ IBM. 4690 OS User's Guide Version 5.2, IBM document SC30-4134-01, 2008-01-10 ([11]).
- ^ a b c d e f g h i j k l m n o p q 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.
- ^ John Elliott (1998). CP/M 4.1 disc formats. ([12]): "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."
- ^ a b vinDaci (1998-01-06). "Long Filename Specification". Retrieved 2007-03-13.
- ^ Henk Kelder. FAT32.TXT for FAT32.IFS version 0.74. ([13]). Comment: This older version of the README file still discusses the old 0xEA and 0xEC magic values.
- ^ Henk Kelder (2003). FAT32.TXT for FAT32.IFS version 0.9.13." ([14]): "This byte [...] is not modified while running Windows 95 and neighter by SCANDISK or DEFRAG. [...] If another program sets the value to 0x00 for a file that has 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".
- ^ Netlabs. FAT32.IFS Wiki and Sources. ([15]).
- ^ a b IBM. 4690 OS Programming Guide Version 5.2, IBM document SC30-4137-01, 2007-12-06 ([16]).
- ^ a b c d e f g h i j k l m n Caldera, Inc. (1997). OpenDOS Developer's Reference Series — System and Programmer's Guide — Programmer's Guide. Printed in the UK, August 1997. Caldera Part No. 200-DODG-003 ([17]).
- ^ Bob Eager, Tavi Systems (2000-10-28). Implementation of extended attributes on the FAT file system. ([18]).
- ^ IBM (2003). Information about 4690 OS unique file distribution attributes, IBM document R1001487, 2003-07-30. ([19]): "[...] 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."
- ^ IBM. 4690 save and restore file distribution attributes. IBM document R1000622, 2010-08-31 ([20]).
- ^ Natuerlich! (1992-03-24). "Getting longer filenames out of GEMDOS". comp.sys.atari.st.tech. Retrieved 2014-05-05.
- ^ Torvalds, Linus (1992-12-23). "Long filenames". comp.os.minix. Retrieved 2014-05-05.
- ^ "mount(8): mount file system". Linux man page.
- ^ "Limitations of FAT32 File System". Microsoft Knowledge Base. 2007-03-26. Retrieved 2011-08-21.
Clusters cannot be 64 kilobytes (KB) or larger
- ^ Duncan, Ray (1989). "Design goals and implementation of the new High Performance File System". Microsoft Systems Journal. [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.]
- ^ Chen, Raymond (July 2006). "Microsoft TechNet: A Brief and Incomplete History of FAT32". Microsoft TechNet Magazine.
- ^ Microsoft.com
- ^ title = FAT%20File%20System "FAT File System". Intellectual Property Licensing. Microsoft.
{{cite web}}
: Check|url=
value (help); Missing pipe in:|url=
(help) - ^ Garrett, Matthew (2012-01-19). "EFI and Linux: the future is here, and it's awful". linux.conf.au. YouTube. Retrieved 2014-01-12.
- ^ Ravicher, Daniel B. (2004-04-15). "PUBPAT's Request for Reexamination of Microsoft's FAT Patent" (PDF). Public Patent Foundation. Retrieved 2014-01-12.
- ^ USPTO (2004-09-30). "Patent Office's Office Action Rejecting Microsoft FAT Patent" (PDF). Public Patent Foundation. Retrieved 2014-01-12.
- ^ Anne Broache (2006-01-10). "Microsoft's file system patent upheld". CNET News. Archived from the original on 2013-01-19. Retrieved 2006-10-14.
- ^ Paul, Ryan (2009-02-25). "Microsoft suit over FAT patents could open OSS Pandora's Box". arstechnica.com. Retrieved 2009-02-28.
- ^ Fried, Ina (2009-03-30). "Microsoft, TomTom settle patent dispute". cnet.com. Retrieved 2009-08-22.
- ^ "Microsoft Motorola Patent Suit". 2010-10-01. Retrieved 2010-10-02.
- ^ Protalinski, Emil (2010-10-01). "Microsoft sues Motorola, citing Android patent infringement". arstechnica.com. Retrieved 2010-10-02.
- ^ Paul, Ryan (2009-07-02). "New Linux patch could circumvent Microsoft's FAT patents". ArsTechnica.com. Retrieved 2013-10-30.
- ^ Brown, Eric (2009-07-02). "Can FAT patch avoid Microsoft lawsuits?". DesktopLinux.Com. Retrieved 2009-08-23.[dead link]
- ^ Florian Müller (2013-12-05). "Federal Patent Court of Germany invalidates Microsoft FAT patent, appeals court may disagree". FOSS Patents. Retrieved 2014-01-12.
External links
- ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange, identical to ISO/IEC 9293.
- Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format
- Understanding FAT32 file systems (explained for embedded firmware developers)
- Understanding FAT including lots of info about LFNs
- Detailed Explanation of FAT Boot Sector: Microsoft Knowledge Base Article 140418
- Description of the FAT32 File System: Microsoft Knowledge Base Article 154997
- FAT12/FAT16/FAT32 file system implementation for *nix: Includes libfat libraries and fusefat, a FUSE file system driver
- MS-DOS: Directory and Subdirectory Limitations: Microsoft Knowledge Base Article 39927
- Overview of FAT, HPFS, and NTFS File Systems: Microsoft Knowledge Base Article 100108
- Volume and file size limits of FAT file systems: Microsoft Technet
- Microsoft TechNet: A Brief and Incomplete History of FAT32 by Raymond Chen
- FAT32 Formatter: allows formatting volumes larger than 32 GiB with FAT32 under Windows 2000, Windows XP and Windows Vista
- Fdisk does not recognize full size of hard disks larger than 64 GB: Microsoft Knowledge Base Article 263044.
- Microsoft Windows XP: FAT32 File System. Copy made by Internet Archive Wayback Machine of an article with summary of limits in FAT32 which is no longer available on Microsoft website.
- Visual Layout of a FAT16 drive