File Allocation Table 1

File Allocation Table

FAT
Developer Microsoft

Full Name File Allocation Table

FAT12 FAT16/FAT16B (16-bit versions) FAT32 (32-bit version with

(12-bit version) 28 bits used)

Introduced August 1980 (QDOS) August 1984 (DOS 3.0 with FAT16), August 1996 (Windows 95
November 1987 (Compaq DOS 3.31 with OSR2)
FAT16B)

MBR Partition 0x01 0x04, 0x06, 0x0E 0x0B, 0x0C

type

GPT Partition Basic data partition

type EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Structures

Directory Table
contents

File allocation Linked list

Bad blocks Cluster tagging

Limits

Max file size 4 GiB minus 1 byte (or block size if smaller)

Max number 4,078

16
65,518 (2 -18)
28
268,435,438 (2 -18)
of clusters 12
(2 -18)

Max cluster 4,079 65,519 268,435,439

[1]
number

Max filename 8.3 filename, or 255 UTF-16 characters when using LFN
size

Max volume size 32 MB 2 GB 2 TB

4 GB with 64 kB clusters (not widely 8 TB (with 32 kB clusters)
supported) 16 TB (with 64 kB clusters,
not widely supported)

Features

Dates recorded Creation, modified, access (accuracy to day only)

(Creation time and access date are only available when ACCDATE support is enabled)

Date range January 1, 1980 - December 31, 2107

Date resolution 2s

Forks Not natively

Attributes Read-only, hidden, system, volume label, subdirectory, archive, (NetWare only) executable

Permissions Global/directory/file-based only with DR-DOS and Multiuser DOS, No

world/group/owner file permissions only with multiuser security

Transparent Per-volume, Stacker, DoubleSpace, DriveSpace No

compression

Transparent Per-volume only with DR-DOS No

encryption
File Allocation Table 2

File Allocation Table (FAT) is a computer file system architecture now widely used on many computer systems and
most memory cards, such as those used with digital cameras. FAT file systems are commonly found on floppy disks,
flash memory cards, digital cameras, and many other portable devices because of their relative simplicity. For floppy
disks, the FAT has been standardized as ECMA-107[2] and ISO/IEC 9293.[3] [4] Those standards include only FAT12
and FAT16 without long filename support; long filenames with FAT is partially patented.[5]
The FAT file system is relatively straightforward technically and is supported by virtually all existing operating
systems for personal computers. This makes it a useful format for solid-state memory cards and a convenient way to
share data between operating systems.

History
Designed and coded by Marc McDonald, Microsoft Stand-alone Disk BASIC introduced the FAT in 1977 with 8-bit
table elements, produced for NCR's 8-bit 8080 file system. The FAT, born during one of a series of discussions
between McDonald and Bill Gates, was later used in a stand-alone BASIC for the 8086 chip and eventually through
the M-DOS operating system, became the basis for the file-handling routines in MS-DOS. In 1980, Tim Paterson
extended the table elements to 12 bits in 86-DOS.[6] [7] [8]
The name originates from the usage of a table which centralizes the information about which areas belong to files,
are free or possibly unusable, and where each file is stored on the disk. To limit the size of the table, disk space is
allocated to files in contiguous groups of hardware sectors called clusters. As disk drives have evolved, the
maximum number of clusters has dramatically 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, 16,
and 32. The FAT standard has also been expanded in other ways while preserving backward compatibility with
existing software.

FAT12
The initial version of FAT designed for 16-bit microprocessors is now referred to as FAT12. Designed as a file
system for floppy disks, it limited cluster addresses to 12-bit values, which not only limited the cluster count to
4078,[9] but made FAT manipulation tricky with the PC's 8-bit and 16-bit registers. (Under Linux, FAT12 is limited
to 4084 clusters.[10] ) The disk's size is stored as a 16-bit count of sectors, which limited the size to 32 MB.[11]
FAT12 was used by several manufacturers with different physical formats, but a typical floppy disk at the time was
5.25-inch, single-sided, 40 tracks, with 8 sectors per track, resulting in a capacity of 160 kB for both the system areas
and files. The FAT12 limitations exceeded this capacity by a factor of ten or more.
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. At the time FAT12 was introduced, DOS did not support hierarchical directories, and the maximum number of
files was typically limited to a few dozen. Hierarchical directories were introduced in MS-DOS version 2.0.[12]
A limitation which was not addressed until much later 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 area, where they made the entire holding cluster unusable as well. FAT12 remains in use on
all common floppy disks, including 1.44 MB ones.
File Allocation Table 3

Initial FAT16
In 1984, IBM released the PC AT, which featured a 20 MB hard disk. Microsoft introduced MS-DOS 3.0 in parallel.
(The earlier PC XT was the first PC with a hard drive from IBM, and MS-DOS 2.0 supported that hard drive with
FAT12.) Cluster addresses were increased to 16-bit, allowing for up to 65,518 clusters per volume, and consequently
much greater file system sizes, at least in theory. However, the maximum possible number of sectors and the
maximum (partition, rather than disk) size of 32 MB did not change. Therefore, although technically already
"FAT16", this format was not what today is commonly understood as FAT16. 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 files several hundred bytes in size, which were
far more common at the time. MS-DOS 2.x hard disks larger than 15 MB are incompatible with later versions of
MS-DOS.[13]
A 20 MB 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 FAT-16. MS-DOS 3.0 could still access MS-DOS 2.0 style 8 kB-cluster partitions
under 15 MB.
MS-DOS 3.0 also introduced support for high-density 1.2 MB 5.25" diskettes, which notably had 15 sectors per
track, hence more space for the FATs. This probably prompted a dubious optimization of the cluster size, which
went down from 2 sectors to just 1. The net effect was that high density diskettes were significantly slower than
older double density ones.

Partitioning and logical drives

Apart from improving the structure of the FAT file system itself, a parallel development allowing an increase in the
maximum possible FAT size was the introduction of multiple FAT partitions on a hard disk. Extra DOS partitions
could not be used as boot partitions. Simply allowing several identical-looking DOS partitions could lead to naming
problems: behaviour if more than one partition was marked active was undocumented (although well defined), as
was the behaviour if there was more than one hard disk in the computer (which was machine dependent), or if the
system was booted from a diskette. The use of third party formatting tools under the DOS complicated the problem
even more.
To allow the use of more FAT partitions in a compatible way, a new partition type was introduced (in MS-DOS 3.2,
January 1986), the extended partition, which is a container for additional partitions called logical drives. A useful
side-effect of the extended partition scheme was to significantly increase the maximum number of partitions possible
on a PC hard disk beyond the four which could be described by the MBR alone.

Final FAT16
Finally in November 1987, Compaq DOS 3.31 (an OEM version of MS-DOS 3.3 released by Compaq with their
machines) introduced what is today called the FAT16 format, with the expansion of the 16-bit disk sector count to 32
bits. The result was initially called the DOS 3.31 Large File System. 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 assembly language.
In 1988 this improvement became more generally available through MS-DOS 4.0 and OS/2 1.1. The limit on
partition size was dictated by the 8-bit signed count of sectors per cluster, which 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 kB clusters, thereby fixing
the "definitive" limit for the FAT16 partition size at 2 gigabytes. On magneto-optical media, which can have 1 or 2
kB sectors instead of 0.5 kB, this size limit is proportionally larger.
Much later, Windows NT increased the maximum cluster size to 64 kB 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
File Allocation Table 4

it generated greater internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk
utilities did not work with it. This contributes to a confusing compatibility situation.
The number of root directory entries available is determined when the volume is formatted, and is stored in a 16-bit
signed field, defining an absolute limit of 32767 entries (32736, a multiple of 32, in practice). For historical reasons,
FAT12 and FAT16 media generally use 512 root directory entries on non-floppy media. Other sizes may be
incompatible with some software or devices (entries being file and/or folder names in the original 8.3 format).[14]
Some third party tools like mkdosfs allow the user to set this parameter.[15]

Long file names

One of the user experience goals for the designers of Windows 95 was the ability to use long filenames (LFNs—up
to 255 UTF-16 code points long), in addition to classic 8.3 filenames. LFNs were implemented using a workaround
in the way directory entries are laid out (see below).
The version of the file system with this extension is usually known as VFAT after the Windows 95 virtual device
driver, also known as "Virtual FAT" in Microsoft's documentation. The VFAT driver appeared before Windows 95,
in Windows for Workgroups 3.11, but was only used for implementing 32-bit file access and did not support long
file names.
In Windows NT, support for long filenames on FAT started from version 3.5. OS/2 added long filename support to
FAT using 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.

FAT32
In order to overcome size limit of FAT16, while at the same time allowing DOS (disk operating system) real mode
code to handle the format, and without reducing available conventional memory unnecessarily, Microsoft expanded
the cluster size yet again, calling the new revision FAT32. Cluster values are represented by 32-bit numbers, of
which 28 bits are used to hold the cluster number, for a maximum of approximately 268 million (228) clusters. This
allows for drive sizes of up to 8 TiB with 32 KiB clusters, but the boot sector uses a 32-bit field for the sector count,
limiting volume size to 2 TiB on a hard disk with 512 byte sectors.
On Windows 95/98, due to the version of Microsoft's DOS-mode SCANDISK utility included with these operating
systems being a 16-bit application, the FAT structure is not allowed to grow beyond 4 177 920 (< 222) clusters,
placing the volume limit at 127.5 GiB (≈137 GB).[16] [17] The FAT32 drive formatting tools provided by Microsoft
(fdisk and format) are thus designed to scale the cluster size upwards as the volume size increases, thereby
preventing the cluster-count from exceeding 4.177 million clusters - and only reaching that number on volumes with
a size of 128 GB with 32 kB cluster size. Most or all appraisals of the efficiency of the FAT32 file system are rooted
in this behavior, as they point out that FAT32 increases the cluster size with the volume size and therefor small file
storage can become very inefficient when larger cluster sizes are used (eg - 32 kB). This behavior, however, is
unnecessary in many cases. Large FAT32 volumes can in fact be created with smaller cluster sizes (eg 4 kB) given
the use of alternate drive preparation tools.
Additionally, there are numerous reports that the DOS scandisk utility provided with Windows 98 (scandisk.exe) and
even Windows 98 itself can in fact operate on FAT32 volumes with cluster counts much higher than the 4.177
million claimed by Microsoft, some of which have been in the 40 to 120 million range, thereby indicating that the
scandisk utility can likely operate on volumes up to the upper limit of the FAT32 specifications.[18] A limitation in
original versions of Windows 98/98SE's Fdisk utility causes it to incorrectly report disk sizes over 64 GiB.[19] A
corrected version is available from Microsoft, but it cannot partition drives larger than 512 GiB (≈550 GB).[20]
Windows 98 (and presumably Windows ME) has been shown to be able to run from and correctly operate with
volumes exceeding 128 GB (up to 1.5 TB in some reports) as well as with FAT32 volumes with 40 to 120 million
clusters, although the native drive maintenance tools (scandskw.exe, defrag) have upper limits that are not yet known
File Allocation Table 5

- but are reported to exceed 20 million clusters when using Windows ME versions of these tools. The Windows
2000/XP installation program and filesystem creation tool imposes a limitation of 32 GiB.[21] However, both systems
can read and write to FAT32 file systems of any size. This limitation is by design and according to Microsoft was
imposed because many tasks on a very large FAT32 file system become slow and inefficient.[16] [22] This limitation
can be bypassed by using third-party formatting utilities or by using the FORMAT command with the /FS:FAT32
switch from the command line.[23]
All versions of Windows prior to XP-SP1 and 2000-SP4 lacked inherent support for 48-bit LBA drive access
because of a limitation in their 32-bit protected-mode IDE driver, meaning that the maximum disk size for (parallel)
ATA disks is 128 GiB (≈137 GB),[24] without using alternate drivers. Windows XP became fully 48-bit LBA
capable with SP1 in 2002, but Microsoft did not release a patch for the 32-bit protected-mode drivers for Windows
98/ME (ESDI_506.PDR) even though those OS's were still being fully supported by Microsoft at that time. Intel did
release an alternate IDE driver for win-9x/me (Intel Application Accelerator) that provides full 48-bit LBA
operability for the 800-series chipsets, and several individuals and user groups have modified Microsoft's
EDSI_506.PDR driver to make it 48-bit LBA compliant for Windows 98. Most or all third-party drivers for SATA
controllers are 48-bit LBA compliant, even when used under Windows 98/ME. All versions of DOS that are FAT-32
aware are also 48-bit LBA capable, so long as 48-bit LBA is supported by the underlying hardware (ie - motherboard
/ BIOS).
FAT32 was introduced with Windows 95 OSR2, although reformatting was needed to use it, and DriveSpace 3 (the
version that came with Windows 95 OSR2 and Windows 98) never supported it. Windows 98 introduced a utility to
convert existing hard disks from FAT16 to FAT32 without loss of data. In the 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.
The maximum possible size for a file on a FAT32 volume is 4 GiB minus 1 byte or 4 294 967 295 (232−1) bytes.
Video applications, large databases, and some other software easily exceed this limit. Larger files require another
filesystem.

Fragmentation
The FAT file system does not contain mechanisms which prevent newly written files from becoming scattered across
the partition.[25] Other file systems, like HPFS, use free space bitmaps that indicate used and available clusters,
which could then be quickly looked up in order to find free contiguous areas (improved in exFAT). 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, computing free disk space on FAT is one of the most resource intensive operations, as it requires reading the
entire FAT linearly. 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.[22] Displaying this line took longer and longer as the number of clusters increased.
The High Performance File System (HPFS) divides disk space into bands, which have their own free space bitmap,
where multiple files opened for simultaneous write could be expanded separately.[25]
Some of the perceived problems with fragmentation resulted from operating system and hardware limitations.
The single-tasking DOS and the traditionally single-tasking PC hard disk architecture (only 1 outstanding
input/output request at a time, no DMA transfers) did not contain mechanisms which could alleviate fragmentation
by asynchronously prefetching next data while the application was processing the previous chunks.
Similarly, write-behind caching was often not enabled by default with Microsoft software (if present) given the
problem of data loss in case of a crash, made easier by the lack of hardware protection between applications and the
system.
File Allocation Table 6

Modern operating systems have introduced these optimizations to FAT partitions, but optimizations can still produce
unwanted artifacts in case of a system crash. A Windows NT system will allocate space to files on FAT in advance,
selecting large contiguous areas, but in case of a crash, files which were being appended will appear larger than they
were ever written into, with dozens of random kilobytes at the end.
With the large cluster sizes, 16 or 32K, forced by larger FAT32 partitions, the external fragmentation becomes
somewhat less significant, and internal fragmentation, i.e. disk space waste (since files are rarely exact multiples of
cluster size), starts to be a problem as well, especially when there are a great many small files.

Third party support

Other IBM PC operating systems—such as Linux, FreeBSD, BeOS and JNode—have all supported FAT, and most
added support for VFAT and FAT32 shortly after the corresponding Windows versions were released. Early Linux
distributions also supported a format known as UMSDOS, which was FAT with Unix file attributes (such as long file
name and access permissions) stored in a separate file called “--linux-.---”. UMSDOS fell into disuse after
VFAT was released and is not enabled by default in Linux kernels from version 2.5.7 onwards.[26] The Mac OS X
operating system also supports the FAT file systems on volumes other than the boot disk. The Amiga supports FAT
through the CrossDOS file system.
A free windows-based FAT32 formatter is available that overcomes many of the arbitrary limitations imposed by
Microsoft.[27]

FAT and Alternate Data Streams

The FAT file system itself is not designed for supporting Alternate Data Streams (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
FINDER.DAT, and resource forks (a common Mac OS ADS) in a subdirectory called RESOURCE.FRK, 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 "._", and Finder stores some folder and file metadata in a hidden file called
".DS Store".
OS/2 heavily depends on extended attributes (EAs) and stores them in a hidden file called "EA DATA. SF" in the
root directory of the FAT12 or FAT16 volume. This file is indexed by 2 previously reserved bytes in the file's (or
directory's) directory entry. In the FAT32 format, these bytes hold the upper 16 bits of the starting cluster number of
the file or directory, hence making it difficult to store EAs on FAT32. Extended attributes are accessible via the
Workplace Shell desktop, through REXX scripts, and many system GUI and command-line utilities (such as
4OS2).[28]
To accommodate its OS/2 subsystem, Windows NT supports the handling of extended attributes in HPFS, NTFS,
and FAT. It stores EAs on FAT and HPFS using exactly the same scheme as OS/2, but does not support any other
kind of 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.
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").
File Allocation Table 7

Future
Microsoft has recently secured patents for VFAT and FAT32 (but not the original FAT). Despite two earlier rulings
against them, Microsoft prevailed and was awarded the patents.
For most 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 or Linux (with NTFS-3G) is finally eroding this
drawback.
FAT is still the normal file system for removable media (with the exception of CDs and DVDs), with FAT12 used on
floppies, and FAT16 or FAT32 on most other removable media (such as flash memory cards for digital cameras and
USB flash drives). Some removable media are not yet large enough to benefit from FAT32; and FAT16 is used on
these drives for reasons of compatibility and size overhead, although some larger flash drives, like SDHC, do make
use of it.

FATX
FATX is a slightly modified version of the FAT filesystem, and is designed for Microsoft's Xbox video game
console hard disk drive and memory cards. FATX is not to be confused with exFAT, described below.

exFAT
exFAT (also sometimes incorrectly and inappropriately known as FAT64) is an incompatible replacement for FAT
file systems that was introduced with Windows Embedded CE 6.0. MBR partition type is 0x7 (the same as NTFS).
exFAT is intended to be used on SDXC and flash drives, where FAT is used today. Microsoft has provided a hotfix
to add support for exFAT to Windows XP,[29] while Windows Vista Service Pack 1 added exFAT support to
Windows Vista.[30]
exFAT introduces a free space bitmap allowing faster space allocation and faster deletes, support for files up to
18,446,744,073,709,551,615 (264-1) bytes, larger cluster sizes (up to 32 MB in the first implementation), an
extensible directory structure and name hashes for filenames for faster comparisons. No short 8.3 filenames are
stored. It does not have security ACLs or file system journaling like NTFS, though device manufacturers can choose
to implement simplified support for transactions (backup file allocation table used for the write operations, primary
FAT for storing last known good allocation table, which is essential for writeable removable media to mitigate
corruption).
File Allocation Table 8

TFAT/TexFAT
TFAT and TexFAT are layers over the FAT and exFAT file systems respectively that provide a level of transaction
safety to reduce the risk of data loss in the event of a power outage or unexpected removal of the drive.

Design

Overview
The following is an overview of the order of structures in a FAT partition or disk:

Contents Boot FS More File File Root Data Region (for files and directories)
Sector Information reserved Allocation Allocation Directory ...
Sector sectors Table #1 Table #2 (FAT12/16 only) (To end of partition or disk)
(FAT32 (optional)
only)

Size in (number of reserved sectors) (number of FATs)*(sectors (number of root NumberOfClusters*SectorsPerCluster

sectors per FAT) entries*32)/Bytes per
sector

A FAT file system is composed of four different sections.

1. The Reserved sectors, located at the very beginning. The first reserved sector (sector 0) is the Boot Sector (aka
Partition Boot Record). 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. The total count of reserved sectors is indicated by a field inside the Boot
Sector. Important information from the Boot Sector is accessible through an operating system structure called the
Drive Parameter Block in DOS and OS/2. For FAT32 file systems, the reserved sectors include a File System
Information Sector at sector 1 and a Backup Boot Sector at Sector 6.
2. The FAT Region. This typically contains two copies (may vary) of the File Allocation Table for the sake of
redundancy checking, although the extra copy is rarely used, even by disk repair utilities. These are maps of the
Data Region, indicating which clusters are used by files and directories. In FAT16 and FAT12 they immediately
follow the reserved sectors.
3. 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.
4. The Data Region. This is where the actual file and directory data is stored and takes up most of the partition. 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 kB file
resides in a 32 kB cluster, 31 kB 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 entries in the header and the FAT(s).
File Allocation Table 9

Boot Sector
The boot sector isn't the first sector on a device. For partitioned devices (such as hard drives), the first sector is the
Master Boot Record. On non-partitioned devices (eg. floppy disk) the first sector is the Volume Boot Record.
Common structure of the first 36 bytes used by all FAT versions are:

Byte Length Description

Offset (bytes)

0x00 3 Jump instruction. This instruction will be executed and will skip past the rest of the (non-executable) header if the partition is
booted from. See Volume Boot Record. If the jump is two-byte near jmp it is followed by a NOP instruction.

0x03 8 OEM Name (padded with spaces 0x20). This value determines in which system disk was formatted. MS-DOS checks this
[31] [32]
field to determine which other parts of the boot record can be relied on. Common values are IBM  3.3 (with two
spaces between the "IBM" and the "3.3"), MSDOS5.0, MSWIN4.1 and mkdosfs.

0x0b 2 Bytes per sector. A common value is 512, especially for file systems on IDE (or compatible) disks. The BIOS Parameter
Block starts here.

0x0d 1 Sectors per cluster. Allowed values are powers of two from 1 to 128. However, the value must not be such that the number of
bytes per cluster becomes greater than 32 kB.

0x0e 2 Reserved sector count. The number of sectors before the first FAT in the file system image. Should be 1 for FAT12/FAT16.
Usually 32 for FAT32.

0x10 1 Number of file allocation tables. Almost always 2.

0x11 2 Maximum number of root directory entries. Only used on FAT12 and FAT16, where the root directory is handled specially.
Should be 0 for FAT32. This value should always be such that the root directory ends on a sector boundary (i.e. such that its
size becomes a multiple of the sector size). 224 is typical for floppy disks.

0x13 2 Total sectors (if zero, use 4 byte value at offset 0x20)

0x15 1 Media descriptor[33]

0xF0 3.5" Double Sided, 80 tracks per side, 18 or 36 sectors per track (1.44MB or 2.88MB). 5.25" Double Sided, 80
tracks per side, 15 sectors per track (1.2MB). Used also for other media types.

0xF8 Fixed disk (i.e. Hard disk).[34]

0xF9 3.5" Double sided, 80 tracks per side, 9 sectors per track (720K). 5.25" Double sided, 80 tracks per side, 15 sectors
per track (1.2MB)

0xFA 5.25" Single sided, 80 tracks per side, 8 sectors per track (320K)

0xFB 3.5" Double sided, 80 tracks per side, 8 sectors per track (640K)

0xFC 5.25" Single sided, 40 tracks per side, 9 sectors per track (180K)

0xFD 5.25" Double sided, 40 tracks per side, 9 sectors per track (360K). Also used for 8".

0xFE 5.25" Single sided, 40 tracks per side, 8 sectors per track (160K). Also used for 8".

0xFF 5.25" Double sided, 40 tracks per side, 8 sectors per track (320K)

Same value of media descriptor should be repeated as first byte of each copy of FAT. Certain operating systems (MSX-DOS
version 1.0) ignore boot sector parameters altogether and use media descriptor value from the first byte of FAT to determine
file system parameters.

0x16 2 Sectors per File Allocation Table for FAT12/FAT16

0x18 2 Sectors per track (Only useful on disks with geometry. [35])

0x1a 2 Number of heads (Only useful on disks with geometry. [35])

0x1c 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.
File Allocation Table 10

0x20 4 Total sectors (if greater than 65535; otherwise, see offset 0x13)

Extended BIOS Parameter Block

Further structure used by FAT12 and FAT16, also known as Extended BIOS Parameter Block:

Byte Length Description

Offset (bytes)

0x24 1 Physical drive number (0x00 for removable media, 0x80 for hard disks)

0x25 1 Reserved ("current head") In Windows NT bit 0 is a dirty flag to request chkdsk at boot time. bit 1 requests surface scan
[34]
too.

0x26 1 Extended boot signature. (Should be 0x29[33] to indicate that an Extended BIOS Parameter Block with the following 3

entries exists. Can be 0x28 on some OS/2 1.x and DOS disks indicating an earlier form of the EBPB format with only the
serial number following.)

0x27 4 ID (serial number)

0x2b 11 Volume Label, padded with blanks (0x20).

0x36 8 FAT file system type, padded with blanks (0x20), e.g.: "FAT12   ", "FAT16   ". This is not meant to be used to determine
drive type, however, some utilities use it in this way.

0x3e 448 Operating system boot code

0x1FE 2 Boot sector signature (0x55 0xAA (for OS/2 1.3 boot diskette))

The boot sector is portrayed here as found on e.g. an OS/2 1.3 boot diskette. Earlier versions used a shorter BIOS
Parameter Block and their boot code would start earlier (for example at offset 0x2b in OS/2 1.1).
Further structure used by FAT32:

Byte Offset Length (bytes) Description

0x24 4 Sectors per file allocation table

0x28 2 FAT Flags (Only used during a conversion from a FAT12/16 volume.)

0x2a 2 Version (Defined as 0)

0x2c 4 Cluster number of root directory start

0x30 2 Sector number of FS Information Sector

0x32 2 Sector number of a copy of this boot sector (0 if no backup copy exists)

0x34 12 Reserved

0x40 1 Physical Drive Number (see FAT12/16 BPB at offset 0x24)

0x41 1 Reserved (see FAT12/16 BPB at offset 0x25)

0x42 1 Extended boot signature. (see FAT12/16 BPB at offset 0x26)

0x43 4 ID (serial number)

0x47 11 Volume Label

0x52 8 FAT file system type: "FAT32   "

0x5a 420 Operating system boot code

0x1FE 2 Boot sector signature (0x55 0xAA)

File Allocation Table 11

Exceptions
The implementation of FAT used in MS-DOS for the Apricot PC 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
file system parameters (offsets 0x0B - 0x17 in the standard sector) were located at offset 0x50. 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.
DOS Plus on the BBC Master 512 did not use conventional boot sectors at all. Data disks omitted the boot sector and
began with a single copy of the FAT (the first byte of the FAT was used to determine disk capacity) while boot disks
began with a miniature ADFS file system containing the boot loader, followed by a single FAT. It could also access
standard PC disks formatted to 180 kB or 360 kB, again using the first byte of the FAT to determine the capacity.

FS Information Sector
The "FS Information Sector" was introduced in FAT32[36] for speeding up access times of certain operations (in
particular, getting the amount of free space). It is located at a sector number specified in the boot record at position
0x30 (usually sector 1, immediately after the boot record).

Byte Offset Length (bytes) Description

0x00 4 FS information sector signature (0x52 0x52 0x61 0x41 / "RRaA")

0x04 480 Reserved (byte values are 0x00)

0x1e4 4 FS information sector signature (0x72 0x72 0x41 0x61 / "rrAa")

0x1e8 4 Number of free clusters on the drive, or -1 if unknown

0x1ec 4 Number of the most recently allocated cluster

0x1f0 14 Reserved (byte values are 0x00)

0x1fe 2 FS information sector signature (0x55 0xAA)

File Allocation Table

A partition 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 kB and 32 kB. 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.
The File Allocation Table (FAT) is a list of entries that map to each cluster on the partition. Each entry records one
of five things:
• the cluster number of the next cluster in a chain
• a special end of clusterchain (EOC) entry that indicates the end of a chain
• a special entry to mark a bad cluster
• a special entry to mark a reserved cluster
• a zero to note that the cluster is unused
The first two entries in a FAT store special values: The first entry contains a copy of the media descriptor (from boot
sector, offset 0x15). The remaining 8 bits (if FAT16), or 20 bits (if FAT32) of this entry are 1.
The second entry stores the end-of-cluster-chain marker. The high order two bits of this entry are sometimes, in the
case of FAT16 and FAT32, used for dirty volume management: high order bit 1: last shutdown was clean; next
highest bit 1: during the previous mount no disk I/O errors were detected.[37]
File Allocation Table 12

Because the first two FAT entries store special values, there is no cluster 0 or 1. The first cluster after the root
directory is cluster 2.
FAT entry values:

FAT12 FAT16 FAT32 Description

0x000 0x0000 0x00000000 Free Cluster

0x001 0x0001 0x00000001 Reserved value; do not use

0x002–0xFEF 0x0002–0xFFEF 0x00000002–0x0FFFFFEF Used cluster; value points to next cluster

0xFF0–0xFF6 0xFFF0–0xFFF6 0x0FFFFFF0–0x0FFFFFF6 Reserved values; do not use.[33]

0xFF7 0xFFF7 0x0FFFFFF7 Bad sector in cluster or reserved cluster

0xFF8–0xFFF 0xFFF8–0xFFFF 0x0FFFFFF8–0x0FFFFFFF Last cluster in file (EOC)

Note that FAT32 uses only 28 bits of the 32 possible bits. The upper 4 bits are usually zero (as indicated in the table
above) but are reserved and should be left untouched.
Each version of the FAT file system uses a different size for FAT entries. Smaller numbers result in a smaller FAT
table, 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 you consider the 3 bytes as one
little-endian 24-bit number, the 12 least significant bits are the first entry and the 12 most significant bits are the
second.

Directory table
A directory table is a special type of file that represents a directory (also known as a folder). Each file or directory
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 date and time of creation, the address of the first
cluster of the file/directory's data and finally the size of the file/directory. 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.
Note that before each entry there can be "fake entries" to support the Long File Name. (See further down the article).
Legal characters for DOS file names 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 be used on the DOS command line prior to
Windows 95 because of the lack of a suitable escaping system)
• ! # $ % & ' ( ) - @ ^ _ ` { } ~
• Values 128–255
This excludes the following ASCII characters:
• " * / : < > ? \ |
Windows/MSDOS has no shell escape character
• + , . ; = [ ]
They are allowed in long file names only.
• Lower case letters a–z
Stored as A–Z. Allowed in long file names.
• Control characters 0–31
File Allocation Table 13

• Value 127 (DEL)

The DOS file names are in the OEM character set.
Directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3
filename):

Byte Length Description

Offset

0x00 8 DOS file name (padded with spaces)

The first byte can have the following special values:

0x00 Entry is available and no subsequent entry is in use

0x05 Initial character is actually 0xE5.

0x2E 'Dot' entry; either '.' or '..'

0xE5 Entry has been previously erased and is available. File undelete utilities must replace this character with a regular
character as part of the undeletion process.

0x08 3 DOS file extension (padded with spaces)

0x0b 1 File Attributes

Bit Mask Description

0 0x01 Read Only

1 0x02 Hidden

2 0x04 System

3 0x08 Volume Label

4 0x10 Subdirectory

5 0x20 Archive

6 0x40 Device (internal use only, never found on disk)

7 0x80 Unused

An attribute value of 0x0F is used to designate a long file name entry.

0x0c 1 Reserved; two bits are used by NT and later versions to encode case information (see below); otherwise 0[38]

0x0d 1 Create time, fine resolution: 10ms units, values from 0 to 199.

0x0e 2 Create time. The hour, minute and second are encoded according to the following bitmap:

Bits Description

15-11 Hours (0-23)

10-5 Minutes (0-59)

4-0 Seconds/2 (0-29)

Note that the seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0d.
File Allocation Table 14

0x10 2 Create date. The year, month and day are encoded according to the following bitmap:

Bits Description

15-9 Year (0 = 1980, 127 = 2107)

8-5 Month (1 = January, 12 = December)

4-0 Day (1 - 31)

0x12 2 Last access date; see offset 0x10 for description.

0x14 2 EA-Index (used by OS/2 and NT) in FAT12 and FAT16, High 2 bytes of first cluster number in FAT32

0x16 2 Last modified time; see offset 0x0e for description.

0x18 2 Last modified date; see offset 0x10 for description.

0x1a 2 Start of file in clusters in FAT12 and FAT16. Low 2 bytes of first cluster in FAT32. Entries with the Volume Label flag,
subdirectory ".." pointing to root, and empty files with size 0 should have first cluster 0.

0x1c 4 File size in bytes. Entries with the Volume Label or Subdirectory flag set should have a size of 0.

Clusters are numbered beginning after the root directory with cluster 2. The following formula will convert the file
start cluster (X) in 0x1a to the number of sectors from the beginning of the partition using the Boot Sector fields:
For FAT32
FileStartSector = ReservedSectors(0x0e) + (NumofFAT(0x10) * Sectors2FAT(0x24)) + ((X − 2) *
SectorsPerCluster(0x0d))
For FAT16/12
FileStartSector = ReservedSectors(0x0e) + (NumofFAT(0x10) * Sectors2FAT(0x16)) + (MaxRootEntry(0x11) * 32 /
BytesPerSector(0x0b)) + ((X − 2) * SectorsPerCluster(0x0d))

Long file names

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.
Older versions of PC-DOS mistake LFN names in the root directory for the volume label, and are likely to display an
incorrect label.
Each phony entry can contain up to 13 UTF-16 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 UTF-16 characters.[38]
After the last UTF-16 character, a 0x00 0x00 is added. The remaining unused characters are filled with 0xFF 0xFF.
LFN entries use the following format:
File Allocation Table 15

Byte Offset Length Description

0x00 1 Sequence Number

0x01 10 Name characters (five UTF-16 characters)

0x0b 1 Attributes (always 0x0F)

0x0c 1 Reserved (always 0x00)

0x0d 1 Checksum of DOS file name

0x0e 12 Name characters (six UTF-16 characters)

0x1a 2 First cluster (always 0x0000)

0x1c 4 Name characters (two UTF-16 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. Bit 7 (0x80) of the sequence number is used to
indicate that the entry is deleted.
For example if we have filename "File with very long filename.ext" it 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 (95, 98, ME) that see all-uppercase filenames if this
File Allocation Table 16

extension has been used, and therefore can change the name of a file when it is transported between OSes, 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.[39]

Third-party extensions
Before Microsoft added support for long filenames and creation/access time stamps, bytes 0x0C–0x15 of the
directory entry were used by alternative operating systems to store additional metadata. These included:

Byte Length System Description

Offset

0x0C 2 RISC OS File type, 0x000 - 0xFFF

0x0C 4 Petrov DOSFS [40] File load address

0x10 4 Petrov DOSFS [40] File execution address

0x0C 1 DOS Plus User-defined file attributes F1-F4

Bit Mask Description

7 0x80 F1

6 0x40 F2

5 0x20 F3

4 0x10 F4

0x0C 1 MSX-DOS 2 For a deleted file, the original first character of the filename.

0x0D 1 DR-DOS For a deleted file, the original first character of the filename.

0x0E 2 DR-DOS and Encrypted file password

FlexOS

0x0E 2 ANDOS File address in the memory

0x10 4 DR-DOS 7 For a deleted file, its original file time and date; deleted files have their normal time and date fields set
to the time of deletion

0x12 2 DR-DOS 6 and File owner ID

FlexOS

0x14 2 DR-DOS and File permissions bitmap (execute permissions are only used by FlexOS):
FlexOS
File Allocation Table 17

Bit Mask Description

0 0x0001 Owner delete requires password

1 0x0002 Owner execute requires password

2 0x0004 Owner write requires password

3 0x0008 Owner read requires password

4 0x0010 Group delete requires password

5 0x0020 Group execute requires password

6 0x0040 Group write requires password

7 0x0080 Group read requires password

8 0x0100 World delete requires password

9 0x0200 World execute requires password

10 0x0400 World write requires password

11 0x0800 World read requires password

FAT licensing
Microsoft applied for, and was granted, a series of patents for key parts of the FAT file system in the mid-1990s.
Being almost universally compatible and well-understood, FAT is frequently chosen as an interchange format for
flash media used in digital cameras and PDAs.
On December 3, 2003 Microsoft announced[41] 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.[42]
To this end, Microsoft cited four patents on the FAT file system as the basis of its intellectual property claims. All
four pertain to long-filename extensions to FAT first seen in Windows 95:
• U.S. Patent 5745902 [43] - Method and system for accessing a file using file names having different file name
formats. Filed July 6, 1992. This covered a means of generating and associating a short, 8.3 filename with long
one (for example, "Microsoft.txt" with "MICROS~1.TXT") and a means of enumerating conflicting short
filenames (for example, "MICROS~2.TXT" and "MICROS~3.TXT"). It is unclear whether this patent would
cover an implementation of FAT without explicit long filename capabilities. Hard links in Unix file systems do
not appear to be prior art: deleting a FAT file via its long name will also remove its short name. Renaming a file
to a "short" name also updates the long file name for coherency; similarly, renaming a file to a "long" name will
allocate a new "short" name. In NTFS, hard links and dual names are separate concepts and each hard link has
two names. Finally, at the API level, both names are always provided together when a directory lookup is
requested from the system; they do not appear as two separate files and do not have to be "matched" to determine
unique files.
• U.S. Patent 5579517 [44] - Common name space for long and short filenames. Filed for on 1995-04-24. This
covers the method of chaining together multiple consecutive 8.3 named directory entries to hold long filenames,
with some of the entries specially marked to prevent their confusing older, long filename-unaware FAT
implementations.
• The Public Patent Foundation successfully challenged this patent; the claims were rejected[45] on 2004-09-14,
due to prior disclosure[46] of the claimed techniques in patents U.S. Patent 5307494 [47] and U.S. Patent
5367671 [48]. This decision was later overturned by the Patent Office on 2006-01-10.
File Allocation Table 18

• U.S. Patent 5758352 [49] - Common name space for long and short filenames. Filed on 1996-09-05. This is very
similar to 5,579,517.
• The Public Patent Foundation successfully challenged this patent (USPTO); The USPTO rejected this patent
on 2005-10-05, on the grounds that "the six assignees names were incorrect".[50] [51] This decision was also
later overturned by the Patent Office on 2006-01-10.
• U.S. Patent 6286013 [52] - Method and system for providing a common name space for long and short file names
in an operating system. Filed on 1997-01-28. This makes claims on the methods used when Windows 95,
Windows 98 and Windows Me expose long filenames to their MS-DOS compatibility layer. It does not appear to
affect any non-Microsoft FAT implementations.
Many technical commentators have concluded that these patents only cover FAT implementations that include
support for long filenames, and that removable solid state media and consumer devices only using short names
would be unaffected.
Additionally, in the document "Microsoft Extensible Firmware Initiative FAT 32 File System Specification, FAT:
General Overview of On-Disk Format" published by Microsoft (version 1.03, 2000-12-06), Microsoft specifically
grants a number of rights, which many readers have interpreted as permitting operating system vendors to implement
FAT.
Microsoft is not the only company to have applied for patents for parts of the FAT file system. Other patents
affecting FAT include:
• U.S. Patent 5367671 [48] - System for accessing extended object attribute (EA) data through file name or EA
handle linkages in path tables. Filed on 1990-09-25 by Barry A. Feigenbaum and Felix Miro of IBM, this makes
claims on the methods used by OS/2, Windows NT, and Linux for storing extended attribute data in the
"EA DATA. SF" file.

Appeal
As there was widespread call for these patents to be re-examined, the Public Patent Foundation (PUBPAT) submitted
evidence to the US Patent and Trade Office (USPTO) disputing the validity of these patents, including prior art
references from Xerox and IBM. The USPTO acknowledged that the evidence raised "substantial new question[s] of
patentability," and opened an investigation into the validity of Microsoft's FAT patents.[53]
On 2004-09-30 the USPTO rejected all claims of U.S. Patent 5579517 [44], based primarily on evidence provided by
PUBPAT. Dan Ravicher, the foundation's executive director, said, "The Patent Office has simply confirmed what we
already knew for some time now, Microsoft's FAT patent is bogus."
According to the PUBPAT press release, "Microsoft still has the opportunity to respond to the Patent Office's
rejection. Typically, third party requests for re-examination, like the one filed by PUBPAT, are successful in having
the subject patent either narrowed or completely revoked roughly 70% of the time."
On 2005-10-05 the Patent Office announced that, following the re-examination process, it had again rejected all
claims of patent 5,579,517, and it additionally found U.S. Patent 5758352 [49] invalid on the grounds that the patent
had incorrect assignees.
Finally, on 2006-01-10 the Patent Office ruled that features of Microsoft's implementation of the FAT system were
"novel and non-obvious", reversing both earlier non-final decisions.[54]
File Allocation Table 19

Patent infringement lawsuits

In February 2009, Microsoft filed a patent infringement lawsuit against TomTom alleging that the device maker's
products infringe on patents related to FAT32 filesystem. As some TomTom products are based on Linux, this
marked the first time that Microsoft tried to enforce its patents against the Linux platform.[55] 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 FAT32 filesystem from its products, and that in return Microsoft not seek legal
action against TomTom for the five year duration of the settlement agreement.[56]
In October 2010, Microsoft filed a patent infringement lawsuit against Motorola alleging several patents (including
two of the FAT32 filesystem patents) were not licensed for use in the Android operating system.[57] They also
submitted a complaint to the ITC.[58]

Workarounds
Developers of open source software have designed methods intended to circumvent Microsoft's patents.[59]

Notes and references

[1] Numbering of clusters begins with 2
[2] standards - Ecma-107 (http:/ / www. ecma-international. org/ publications/ standards/ Ecma-107. htm)
[3] standards - ISO 9293:1987 (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_ics/ catalogue_detail_ics. htm?csnumber=16948)
[4] standards - ISO/IEC 9293:1994 (http:/ / www. iso. org/ iso/ iso_catalogue/ catalogue_tc/ catalogue_detail. htm?csnumber=21273)
[5] US Patent 5758352 (http:/ / patft. uspto. gov/ netacgi/ nph-Parser?patentnumber=5758352)
[6] Duncan, Ray, 1988. The MS-DOS Encyclopedia, Microsoft Press. ISBN 1-55615-049-0.
[7] Wallace & Erickson, 1992. Hard Drive, John Wiley & Sons. ISBN 0-471-56886-4.
[8] Blogspot.com (http:/ / dosmandrivel. blogspot. com/ 2007/ 09/ design-of-dos. html)
[9] Brian Jenkinson, Sammes, A. J. (2000). Forensic Computing: A Practitioner's Guide (Practitioner Series). Berlin: Springer. pp. 157.
ISBN 1-85233-299-9. "...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."
[10] Andries Brouwer. "FAT Under Linux" (http:/ / www. win. tue. nl/ ~aeb/ linux/ fs/ fat/ fat-2. html). . Linux source code related to DOS often
contains: #define MSDOS_FAT12 4084 (see line 76 of "KernelAPI: msdos_fs.h" (http:/ / www. kernel-api. org/ docs/ online/ 2. 2. 26/ dc/
dd8/ msdos__fs_8h-source. html). .).
[11] File allocation is specified using binary meanings for K (10241 instead of 10001), M (10242 instead of 10002), G (10243 instead of 10003), ...
[12] "MS-DOS History" (http:/ / www. nukesoft. co. uk/ msdos/ dosversions. shtml). .
[13] Microsoft Knowledge Base article: "MS-DOS Partitioning Summary" (http:/ / support. microsoft. com/ kb/ q69912/ )
[14] "Errors Creating Files or Folders in the Root Directory" (http:/ / support. microsoft. com/ kb/ 120138). Microsoft Help and Support.
December 16, 2004. . Retrieved 2006-10-14.
[15] "mkdosfs man page" (http:/ / www. die. net/ doc/ linux/ man/ man8/ mkdosfs. 8. html). .
[16] "Limitations of FAT32 File System" (http:/ / support. microsoft. com/ kb/ 184006/ en-us). Microsoft Help and Support. 2004-12-16. .
Retrieved 2006-10-14.
[17] 4,177,920 x 32 KiB = 127.5 GiB (http:/ / www. wolframalpha. com/ input/ ?i=4,177,920+ x+ 32+ KiB+ in+ GiB)
[18] Guy, 98 (2007). Usenet: Cluster size and exploring the limits of FAT-32 (http:/ / groups. google. com/ group/ microsoft. public. win98.
gen_discussion/ msg/ cf15325586abfa68). Usenet Windows-98 newsgroup February 2007.
[19] "Fdisk Does Not Recognize Full Size of Hard Disks Larger than 64 GB" (http:/ / support. microsoft. com/ kb/ 263044). Microsoft Help and
Support. 2007-01-27. . Retrieved 2007-03-08.
[20] Fdisk.exe Unable to Partition Drives Larger Than 512 Gigabytes (http:/ / support. microsoft. com/ ?kbid=280737)
[21] "Limitations of the FAT32 File System in Windows XP" (http:/ / support. microsoft. com/ kb/ 314463/ en-us). Microsoft Help and Support.
2002-09-04. . Retrieved 2007-01-24.
[22] Chen, Raymond (2006). Microsoft TechNet: A Brief and Incomplete History of FAT32 (http:/ / www. microsoft. com/ technet/ technetmag/
issues/ 2006/ 07/ WindowsConfidential/ ). TechNet Magazine July 2006.
[23] Fat32Format (http:/ / www. ridgecrop. demon. co. uk/ index. htm?fat32format. htm) - Windows program for formatting disks as FAT32
beyond the 32 GB limit.
[24] 228 x 512 byte sectors = 128 GiB (http:/ / www. wolframalpha. com/ input/ ?i=2^28+ *+ 512+ byte+ in+ GiB)
[25] Duncan, Ray (1989). "Design goals and implementation of the new High Performance File System" (http:/ / cd. textfiles. com/ megademo2/
INFO/ OS2_HPFS. TXT). Microsoft Systems Journal. . [Note: This particular text file has a number of 'scan' errors; e.g., "Ray" is the author's
correct name; not 'Roy' as text shows.]
File Allocation Table 20

[26] "Release notes for v2.5.7" (http:/ / www. kernel. org/ pub/ linux/ kernel/ v2. 5/ ChangeLog-2. 5. 7). The Linux Kernel archives. 2002-03-12.
. Retrieved 2006-10-14.
[27] "fat32format" (http:/ / www. ridgecrop. demon. co. uk/ index. htm?fat32format. htm). Ridgecrop Consultants Ltd. . Retrieved 2009-11-16.
[28] Bob Eager (2000-10-28). "Implementation of extended attributes on the FAT file system" (http:/ / www. tavi. co. uk/ os2pages/ eadata.
html). Tavi OS/2 pages. . Retrieved 2006-10-14.
[29] "Update for Windows XP (KB955704)" (http:/ / www. microsoft. com/ downloads/ details.
aspx?FamilyID=1cbe3906-ddd1-4ca2-b727-c2dff5e30f61& displaylang=en). Microsoft. . Retrieved 2010-01-07.
[30] Brandon LeBlanc (2007-08-28). "Vista SP1 Whitepaper" (http:/ / windowsvistablog. com/ blogs/ windowsvista/ pages/
windows-vista-service-pack-1-beta-whitepaper. aspx#_Toc175944550). Microsoft. . Retrieved 2007-08-28.
[31] Matthias Paul (2002-02-20). "Need DOS 6.22 (Not OEM)" (http:/ / groups. google. com/ group/ alt. msdos. programmer/ msg/
6b10a1ea602e61e). alt.msdos.programmer. . Retrieved 2006-10-14.
[32] Wally Bass (1994-02-14). "Cluster Size" (http:/ / groups. google. co. uk/ group/ comp. os. msdos. programmer/ msg/ 79de2d76832cfbd6).
comp.os.msdos.programmer. . Retrieved 2006-10-14.
[33] Microsoft MS-DOS Programmer's Reference : version 5.0. Microsoft press. 1991. ISBN 1-55615-329-5.
[34] "Detailed Explanation of FAT Boot Sector" (http:/ / support. microsoft. com/ kb/ 140418). . Retrieved 2008-11-21.
[35] http:/ / download. microsoft. com/ download/ 1/ 6/ 1/ 161ba512-40e2-4cc9-843a-923143f3456c/ fatgen103. doc
[36] "Detailed Explanation of FAT Boot Sector" (http:/ / www. dewassoc. com/ kbase/ hard_drives/ boot_sector. htm). DEW Associates
Corporation. 2002. . Retrieved 2009-02-15.
[37] Andries E. Brouwer (2002-09-20). "The FAT filesystem" (http:/ / www. win. tue. nl/ ~aeb/ linux/ fs/ fat/ fat-1. html). . Retrieved
2006-10-14.
[38] vinDaci (1998-01-06). "Long Filename Specification" (http:/ / www. teleport. com/ ~brainy/ lfn. htm). . Retrieved 2007-03-13.
[39] "mount(8): mount file system – Linux man page" (http:/ / linux. die. net/ man/ 8/ mount). .
[40] http:/ / mdfs. net/ Apps/ Filing/ DOSFS
[41] Microsoft.com (http:/ / www. microsoft. com/ presspass/ press/ 2003/ dec03/ 12-03ExpandIPPR. mspx)
[42] "Intellectual Property Licensing – FAT File System" (http:/ / www. microsoft. com/ iplicensing/ productDetail. aspx?productTitle=FAT File
System). Microsoft. .
[43] http:/ / www. google. com/ patents?vid=5745902
[44] http:/ / www. google. com/ patents?vid=5579517
[45] "At PUBPAT's request, patent office rejects Microsoft's FAT patent: Government Relies Heavily on Evidence Submitted by PUBPAT"
(http:/ / www. pubpat. org/ Microsoft_517_Rejected. htm). Public Patent Foundation. 2004-09-30. . Retrieved 2006-10-14.
[46] Ina Fried (2004-09-30). "Microsoft FAT patent falls flat" (http:/ / news. com. com/ Microsoft+ FAT+ patent+ falls+ flat/
2100-1014_3-5390138. html). CNET News. . Retrieved 2006-10-14.
[47] http:/ / www. google. com/ patents?vid=5307494
[48] http:/ / www. google. com/ patents?vid=5367671
[49] http:/ / www. google. com/ patents?vid=5758352
[50] Andrew Orlowski (2005-10-05). "Microsoft FAT patent rejected - again" (http:/ / www. regdeveloper. co. uk/ 2005/ 10/ 05/
microsoft_patent/ ). The Register. . Retrieved 2006-10-14.
[51] "Patent Office rejects two Microsoft FAT patents" (http:/ / www. out-law. com/ default. aspx?page=6202). out-law.com. 2005-06-10. .
Retrieved 2006-10-14.
[52] http:/ / www. google. com/ patents?vid=6286013
[53] Andrew Orlowski (2004-06-14). "Microsoft's war on GPL dealt patent setback" (http:/ / www. theregister. co. uk/ 2004/ 06/ 14/
ms_fat_patent_reexamined/ ). The Register. . Retrieved 2006-10-14.
[54] Anne Broache (2006-01-10). "Microsoft's file system patent upheld" (http:/ / news. com. com/ Microsofts+ file+ system+ patent+ upheld/
2100-1012_3-6025447. html). CNET News. . Retrieved 2006-10-14.
[55] Paul, Ryan (2009-02-25). "Microsoft suit over FAT patents could open OSS Pandora's Box" (http:/ / arstechnica. com/ microsoft/ news/
2009/ 02/ microsoft-sues-tomtom-over-fat-patents-in-linux-based-device. ars). arstechnica.com. . Retrieved 2009-02-28.
[56] Fried, Ina (2009-03-30). "Microsoft, TomTom settle patent dispute" (http:/ / news. cnet. com/ 8301-13860_3-10206988-56. html). cnet.com.
. Retrieved 2009-08-22.
[57] "Micrsoft Motorola Patent Suit" (http:/ / www. scribd. com/ doc/ 38550703/ Micrsoft-Motorola-Patent-Suit). 2010-10-01. . Retrieved
2010-10-02.
[58] Protalinski, Emil (2010-10-01). "Microsoft sues Motorola, citing Android patent infringement" (http:/ / arstechnica. com/ microsoft/ news/
2010/ 10/ microsoft-sues-motorola-citing-android-patent-infringement. ars). arstechnica.com. . Retrieved 2010-10-02.
[59] Brown, Eric (2009-07-02). "Can FAT patch avoid Microsoft lawsuits?" (http:/ / www. desktoplinux. com/ news/ NS4980952387.
html?kc=rss). DesktopLinux.Com. . Retrieved 2009-08-23.
File Allocation Table 21

External links
• ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange (http://www.
ecma-international.org/publications/standards/Ecma-107.htm), identical to ISO/IEC 9293.
• Microsoft Extensible Firmware Initiative FAT 32 File System Specification, FAT: General Overview of On-Disk
Format (http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx)
• Understanding FAT32 Filesystems (explained for embedded firmware developers) (http://www.pjrc.com/tech/
8051/ide/fat32.html)
• Understanding FAT (http://users.iafrica.com/c/cq/cquirke/fat.htm) including lots of info about LFNs
• Detailed Explanation of FAT Boot Sector (http://support.microsoft.com/kb/140418/) - Microsoft Knowledge
Base Article 140418
• Description of the FAT32 File System (http://support.microsoft.com/kb/154997/) - Microsoft Knowledge
Base Article 154997
• FAT12 / FAT16/ FAT32 Filesystem implementation for *nix (http://sourceforge.net/projects/libfat/) -
Includes libfat libraries and fusefat , a FUSE filesystem driver
• MS-DOS: Directory and Subdirectory Limitations (http://support.microsoft.com/kb/39927/) - Microsoft
Knowledge Base Article 39927
• Overview of FAT, HPFS, and NTFS File Systems (http://support.microsoft.com/kb/100108/) - Microsoft
Knowledge Base Article 100108
• Volume and file size limits of FAT file systems (http://www.microsoft.com/technet/prodtechnol/winxppro/
reskit/c13621675.mspx) - Microsoft Technet
• Microsoft TechNet: A Brief and Incomplete History of FAT32 (http://www.microsoft.com/technet/
technetmag/issues/2006/07/WindowsConfidential/) by Raymond Chen
• FAT 32 Formatter (http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm): allows formatting
volumes larger than 32 GB with FAT32 under Windows 2000, Windows XP and Windows Vista
• Fdisk Does Not Recognize Full Size of Hard Disks Larger than 64 GB (http://support.microsoft.com/kb/
263044) - Microsoft Knowledge Base Article 263044.
• Microsoft Windows XP - FAT32 File System (http://web.archive.org/web/20050319235548/www.microsoft.
com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_cycz.asp) - Copy made by Internet
Archive Wayback Machine (http://www.archive.org/) of an article with summary of limits in FAT32 which is
not longer available on Microsoft website.
• EFSL (http://sf.net/projects/efsl), Open source FAT implementation for embedded devices
• Visual Layout of a FAT16 drive (http://www.beginningtoseethelight.org/fat16/)
• Understand the Master Boot Record of FAT16 (http://www.viralpatel.net/taj/tutorial/fat.php)
• Utility to read, remove and extract files on FAT12, 16 and 32 (http://gitorious.org/unix-stuff/fat-util)
Article Sources and Contributors 22

Article Sources and Contributors

File Allocation Table  Source: http://en.wikipedia.org/w/index.php?oldid=429590712  Contributors: -Majestic-, A Raider Like Indiana, A3RO, ABach, Abdull, Adam Mirowski, Admiral
Norton, Ae-a, Aeons, Aiden McShane, Akhristov, Alanthehat, Alecv, Alexander Abramov, Ali@gwc.org.uk, AlistairMcMillan, Anastasios, Andrzej P. Wozniak, Angela, AnonMoos, Antaeus
Feldspar, AntonioMartin, Ap, Arsenalboi17, Asymmetric, Azarien, BDinkevich, Bachvudao, Balloonguy, Belg4mit, BenRG, Bendy, Beraldoleal, Bevo, Bk0, Bletch, Bobblewik, Bobo192, Borgx,
Bourgeoisdude, Brian Patrie, Brian0918, Briandgregory, Brim, Bytbox, CA387, COstop, Catslash, Cek, Cenarium, Certh, Cfsenel, Chmod007, Chnv, ChrisMP1, Chrisjj, Clarky3429, Claunia,
ClearZ, Clueless, Cmdrjameson, Colin Watson, CovenantD, Cpiral, CrazyTerabyte, Cruicky, Cyraan, DNewhall, Dajhorn, Damian Yerrick, DariuszT, Dav7, DaveJB, David Gerard,
Dayofswords, Ddxc, Demitsu, Denelson83, Destynova, DevinCurrie, Dgies, Dhochron, Diamondland, Dispenser, Dohzer, DonnEdwards, Dougofborg, Dpbsmith, Dpwkbw, Drilnoth, Dsav,
Dwedit, Dwheeler, Dynaflow, Długosz, EJSawyer, Ebyabe, Ed Brey, Ed Poor, Efilnickufesin, Electron9, Ellywa, Elsendero, Emperorbma, Emuroms, EncMstr, Erkekjetter, Evert Mouw, Evice,
Farmercarlos, Felipe1982, Fixman88, Fnagaton, FocalPoint, Franciozzy, Frankk74, Frap, Fratrep, Fred Bradstadt, Freddyzdead, Furrykef, Gadfium, Gaius Cornelius, GarethH1, Gazpacho,
Gbeeker, Gene Thomas, Geoffrey, GerardM, Ghakko, Ghettoblaster, Gigs, Givegains, Glider87, Groogle, Gurch, Guy Harris, Haipa Doragon, Headbomb, Hede2000, Helpsloose, Herb.Oxley,
Hervegirod, Hmrox, Holmenhhs, I do not exist, I80and, ITurtle, Ice Cold Beer, IceHunter, Incnis Mrsi, Info@segger-us.com, Intgr, Isaac Dupree, Isidore, J.delanoy, JLM, Jacob Poon, James
Michael 1, Jernejl, Jerome Charles Potts, Jgharston, Jimmi Hugh, Jketola, Jkew, Jonathan de Boyne Pollard, Josh the Nerd, Josh3580, Julio.maranhao, Jumager, Jusdafax, Jwy, KAMiKAZOW,
KaiSeun, Kbahey, Kbolino, Kesla, Kitplane01, Kohtala, Komitsuki, Krótki, Kundor, Kuzetsa, Kyz, L33th4x0rguy, LaikaN57, Lamp90, Lavenderbunny, Ledow, Ligulem, Linton, Lord of the Pit,
Lotje, Lucy-seline, Luigiacruz, MC10, Mac, Macbirdie, Maester mensch, Mahjongg, Mandarax, Mange01, Marcan, MarkMLl, MarkSweep, Martijn Hoekstra, Martin451, Mathias-S, MattGiuca,
Matticus78, Maxim, Mazin07, Mazza17206, Mdf, Megya, Mellery, Menkhaf, Mephiles602, MetaEntropy, Michael Hardy, Michael Niemann, Michael%Sappir, Michaelkourlas, Middayexpress,
Midgrid, Mike3211, MikeRS, Mikus, Milan Keršláger, Modest Genius, Monterey Bay, Mormegil, Moxfyre, Mr Icekirby, Mschlindwein, Mulad, Mwaisberg, Mwtoews, Naelphin, Napalm Llama,
Nard the Bard, NeqO, NightFalcon90909, Nil Einne, Noctibus, Nono64, Not2advanced, Now3d, Nsbendel, Ntsimp, Numbo3, Oben, Oconnor663, Oddity-, Omegatron, Oneiros, Onorem, Ornil,
Oxymoron83, Patrick, Paul Stansifer, Paul1337, Peasant82, Pengkeu, Peter.McIntyre, Peyre, Phatom87, Phil Holmes, PhilKnight, PierreAbbat, Plasticup, Plugwash, Pmsyyz, Postdlf, Public
Menace, Pwroberts, QVanillaQ, R'n'B, Raccoon Fox, Random832, Raph, RattleMan, Reboot, Reedy, Rees11, Reisio, Reswobslc, Rfc1394, Rfl, Rg stephens, Rich Farmbrough, Richardguk,
Rjwilmsi, Rmhermen, RobertG, Rockpool, Ronbo76, Roozbeh, Rsduhamel, Ruud Koot, Rwessel, RxS, Ryansturmer, Ryulong, S Roper, SDS, Sade, Safalra, Samboy, Sangheili Fleet, Saxbryn,
Sbmeirow, Scepia, Scientus, Scott McNay, Sct72, Sephiroth BCR, Sfisher, ShadowRangerRIT, ShakespeareFan00, Simsong, Sinan Taifour, SoCalSuperEagle, SolarisBigot, Solitude, Soumyasch,
Spitzak, Stephenb, SterlingNorth, Strangnet, Tangodevian, Tarquin, Tarun., TechControl, Techdawg667, Techtoucian, Tedickey, Tempel, Temporaluser, The Anome, TheAlmightyEgg,
TheRanger, TheStarman, Thematrixeatsyou, Thingg, Thunderbird2, Thunderpenguin, Tide rolls, Tirdun, TobiasHerp, Toby Douglass, Tony22r, Tonybenham, Toytoy, Travis Evans, TrevMrgn,
TrygveFlathen, Twintop, USE NOTES, Ubern00b, Uli, Uncle G, Uriyan, Uzume, Vanished user 34958, Vanuan, Vegaswikian, Veinor, Vezhlys, Vfs, VoiceOfReason, Voidxor, W.F.Galway,
Walter Görlitz, Warren, Wbm1058, Webmusher, Weevil, Wernher, Wiedemann, Wik, WillOakland, William Avery, Wknight94, WooperJeff, Wzwz, Xnquist, Yuhong, ZeroUm, Zytron, 818
anonymous edits

License
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/