File Allocation Table: Difference between revisions

FAT
Developer(s)	Microsoft
Full name	File Allocation Table; FAT12 (12-bit version); FAT16/FAT16B (16-bit versions); FAT32 (32-bit version with 28 bits used)
Introduced	FAT12: August 1980 (QDOS); FAT16: August 1984 (DOS 3.0 with FAT16), November 1987 (Compaq DOS 3.31 with FAT16B); FAT32: August 1996 (Windows 95 OSR2)
Partition IDs	FAT12: 0x01; FAT16: 0x04, 0x06, 0x0E; FAT32: 0x0B, 0x0C
Structures
Directory contents	Table
File allocation	Linked list
Bad blocks	Cluster tagging
Limits
Max volume size	FAT12: 32 MB; FAT16: 2 GB (4 GB for 64 kB clusters); FAT32: 2 TB (16 TB for 4 kB sectors)
Max file size	4 GB minus 1 byte
Max no. of files	FAT12: 4,084 (212-12); FAT16: 65,524 (216-12); FAT32: 268,435,444 (228-12)
Max filename length	8.3 filename, or 255 UTF-16 characters when using LFN
Features
Dates recorded	Modified, creation, 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	2 seconds (10ms with VFAT)
Forks	Not natively
Attributes	Read-only, Hidden, System, Volume, Directory, Archive
File system; permissions	FAT12/FAT16: Global/directory/file-based passwords for Read, Write, Delete, Execute access rights only with DR-DOS, FlexOS, PalmDOS, Novell DOS, OpenDOS, Multiuser DOS and REAL/32 (Execute only with FlexOS), World/Group/Owner file permissions only with multiuser security; FAT32: No
Transparent; compression	FAT12/FAT16: Per-volume, Stacker, DoubleSpace, DriveSpace; FAT32: No
Transparent; encryption	FAT12/FAT16: Per-volume only with DR-DOS; FAT32: No

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 14:30, 19 December 2011

File Allocation Table (FAT) is a computer file system architecture. FAT is 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. 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.

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 FAT represents a map of so called clusters, chunks of individually allocatable blocks of contiguous logical sectors into which the volume's storage area is divided by the number of FAT entries. Ascending cluster numbers address logically subsequent chunks of storage space on the volume, while the cluster number also works as an index into the FAT at the same time. Very low and very high cluster numbers are reserved to mark free, special purpose, defective or otherwise unusable areas in the volume's image. The remaining cluster values correspond with allocatable chunks. Files and directories are organized in cluster chains, where allocated clusters are indicated by a non-zero value in the corresponding entry in the FAT. If a file spawns over more than one cluster, the corresponding entry in the FAT works as pointer to the next used cluster in the chain, whereas a reserved but non-zero value indicates the end of a file's cluster chain.

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.

For floppy disks, the FAT has been standardized as ECMA-107^[2] and ISO/IEC 9293.^[3] These standards cover FAT12 and FAT16 with only short 8.3 filename support; long filenames with FAT are partially patented.^[4]

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 in the M-DOS operating system.

In 1980, while borrowing Microsoft's FAT concept for Seattle Computer Products' 86-DOS, Tim Paterson extended the table elements to 12 bits for his implementation of FAT12, whereas the 8-bit file system precursor was not supported by 86-DOS. 86-DOS supported 8-inch floppy drives and later evolved into MS-DOS/PC DOS.^[5]^[6]^[7]

IBM PC DOS 1.0, released with the original IBM Personal Computer in 1981, supported single-sided 5.25-inch floppy drives, and PC DOS 1.1 added double-sided support. Neither of these versions had a BIOS parameter block. The BPB was introduced in PC DOS 2.0. 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 attributes included a hidden bit and system bit, with the remaining six bits undefined. PC DOS 2.0 added read-only, volume label, subdirectory and archive attribute bits.

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 4084,^[2]^[8]^[9] but made FAT manipulation tricky with the PC's 8-bit and 16-bit registers. (The literature also mentions a limit 4078.^[10]^[11]) The disk's size is stored as a 16-bit count of sectors, which limited the size to 32 MB. 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 containing cluster unusable. FAT12 remains in use on all common floppy disks, including 1.44 MB disks.

The PC XT was the first PC with a hard drive from IBM, and MS-DOS 2.0 supported that hard drive with FAT12.^{[citation needed]}

Initial FAT16

In 1984, IBM released the PC AT, which featured a 20 MB hard disk. 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 (partition, rather than disk) size of 32 MB did not change. Therefore, although cluster addresses were 16 bits, 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 FAT16. 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.

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. 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 an additional partition called logical drive and optionally another extended partition containing the next logical drive, and so on. The 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.

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 today is simply known as 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. FAT16 partition type hex. 04 indicates less than 65536 sectors (less than 32 MB for sector size 512), type 06 indicates 65536 or more sectors, and hex. 0E indicates LBA instead of CHS addressing. Microsoft's dskprobe tool refers to type 06 as BigFAT,^[14] whereas some older versions of FDISK described it as BIGDOS. It is also known as FAT16B.

In 1988 this improvement became more generally available through DR DOS 3.31, 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 GB for sector size 512. 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 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 for FAT12 and FAT16 is determined when the volume is formatted, and is stored in a 16-bit field. For a given number RDE and sector size SS the number RDS of root directory sectors is RDS=ceil((RDE×32)/SS), and RDE is normally chosen to fill these sectors, i.e., RDE*32=RDS*SS. FAT12 and FAT16 media typically use 512 root directory entries on non-floppy media.^[15] Some third-party tools like mkdosfs allow the user to set this parameter.^[16]

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. For backward 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 (see below).
This transparent method to store long file names in the existing FAT file systems without altering their data structures is usually known as VFAT (for "Virtual FAT") after the Windows 95 virtual device driver. (A driver named 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 names.)
In Windows NT, support for VFAT long filenames started from version 3.5.
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.
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 the 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. The boot sector uses a 32-bit field for the sector count, limiting the FAT32 volume size to 2 TB for sector size of 512 bytes and 16 TB for sector size of 4,096 bytes.^[17]^[18]
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 GB minus 1 byte or 4 294 967 295 (2³²−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.^[1] Video applications, large databases, and some other software easily exceed this limit. Larger files require another filesystem.
As with previous filesystems, the design of the FAT32 filesystem does not include direct built-in support for long filenames, but FAT32 volumes can optionally hold 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.

Future

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).

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.^[19]^[20] On-disk datestamps differ slightly between FAT and FATX: in FAT, the epoch is 1980; in FATX, the epoch is 2000. On the Xbox 360, the epoch is 1980.^[21]

exFAT

Main article: exFAT

exFAT is an incompatible, proprietary and patent protected replacement for FAT file systems that was introduced with Windows Embedded CE 6.0. The MBR partition type is 0x07 (the same as for IFS, HPFS, NTFS, etc.). exFAT is intended to be used on flash drives (such as SDXC and Memory Stick XC), where FAT is used today. It offers no practical benefits over FAT32 for volumes smaller than 2 TB and file sizes between 64 KB and 4 GB, but makes data exchange more difficult, since many existing operating systems do not technically or cannot legally support exFAT.

Design


Overview of the order of structures in a FAT partition or disk


Contents

Boot Sector

FS Information Sector (FAT32 only)

More reserved sectors (optional)

File Allocation Table #1

File Allocation Table #2

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

NumberOfClusters*SectorsPerCluster

A FAT file system is composed of four different sections.

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.
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.
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. 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). It is possible to allocate more FAT sectors than necessary for the number of clusters. The end of the last FAT sector 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), 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 volume.

Boot Sector

On non-partitioned devices, e.g., floppy disks, the boot sector is the first sector. 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 FAT 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


0x00

3

Jump instruction. If the boot sector has a valid signature residing in the last two bytes of the boot sector, 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. Valid x86-bootable disks must start with either a jump (opcodes EB hex or E9 hex) or a NOP (90 hex). If the jump is a two-byte near jmp it is followed by a NOP instruction (EB??90 hex).


0x03

8

OEM Name (padded with spaces 0x20). This value determines in which system the disk was formatted. MS-DOS/PC DOS (since 3.0), Windows 95/98/SE/ME and OS/2 check this field to determine which other parts of the boot record can be relied on and how to interpret them. 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.^[22]^[23] Common examples are IBM␠␠3.3, MSDOS5.0, MSWIN4.1, mkdosfs␠, and FreeDOS␠. Some vendors store licensing info or access keys in this entry. The Volume Tracker in Windows 95/98/SE/ME will overwrite the OEM label with ?????IHC signatures (a left-over from ␠OGACIHC for "Chicago") even on a seemingly read-only disk access (such as "DIR A:") if the medium is not write-protected. Given the dependency on certain values explained above, this may, depending on the BPB format used, cause MS-DOS/PC DOS, Windows 95/98/SE/ME and OS/2 to no longer recognize the medium and throwing error messages despite the fact that the medium is not actually defective and can still be read on other operating systems.^[24]

BIOS Parameter Block

Common structure of the first 25 bytes of the BIOS Parameter Block (BPB) used by most FAT versions since DOS 2.0 are:



Byte Offset

Length (bytes)

Description


0x0B

2

Bytes per logical sector in powers of two; the most common value is 512. 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 65534 logical sectors. The minimum practical value is 128. Some old pre-DOS 3.31 OEM versions of DOS used logical sector sizes up to 8192 bytes. Some Advanced Format hard disks use 4096 bytes per sector. The BIOS Parameter Block starts here.


0x0D

1

Logical sectors per cluster. Allowed values are powers of two from 1 to 128. MS-DOS/PC DOS and Windows 95 support a maximum cluster size of 32 KB only. Windows 98/SE/ME partially support a cluster size of 64 KB as well. The Windows NT family and some alternative DOS versions fully support 64 KB clusters. For DOS-based operating systems, the maximum cluster size remains at 32 KB or 64 KB even for sector sizes larger than 512 bytes.


0x0E

2

Reserved logical sector count. The number of logical sectors before the first FAT in the file system image. At least 1 for this sector, usually 32 for FAT32.


0x10

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, whereas DR-DOS does.


0x11

2

Maximum number of FAT12 or FAT16 root directory entries. 0 for FAT32, where the root directory is stored in ordinary data clusters.


0x13

2

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


0x15

1

Media descriptor^[25]
0xF0
3.5" Double Sided, 80 tracks per side, 18 or 36 sectors per track (1.44MB or 2.88MB)
Used also for other media types such as tapes.^[26]
0xF8
Fixed disk (i.e., typically a partition on a Hard disk).^[27]
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)
8" Double sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (500.5K)
0xFE
5.25" Single sided, 40 tracks per side, 8 sectors per track (160K)
8" Single sided, 77 tracks per side, 26 sectors per track, 128 bytes per sector (250.25K)
8" Double sided, 77 tracks per side, 8 sectors per track, 1024 bytes per sector (1232K)
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

Logical sectors per File Allocation Table for FAT12/FAT16, 0 for FAT32 (cf. offset 0x24 below)


0x18

2

Sectors per track for disks with geometry,^[8] e.g., 18 for a 1.44MB floppy


0x1A

2

Number of heads for disks with geometry,^[8] e.g., 2 for a double sided floppy


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.


0x20

4

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

A simple formula translates a given cluster number CN to a logical sector number LSN:^[2]

Determine (once) SSA=RSC+FN×SF+ceil((32×RDE)/SS), where the reserved sector count RSC is stored at offset 0x0E, the FAT number FN at offset 0x10, the sectors per FAT SF at offset 0x16 (FAT12/FAT16) or 0x24 (FAT32), the root directory entries RDE at offset 0x11, the sector size SS at offset 0x0B, and ceil(x) rounds up to a whole number.
Determine LSN=SSA+(CN-2)×SC, where the sectors per cluster SC are stored at offset 0x0D.

A translation of CHS to LSN is also simple: LSN=SPT×(HN+(NOS×TN))+SN-1, where the sectors per track SPT are stored at offset 0x18, and the number of sides NOS at offset 0x1A. 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, also known as Extended BIOS Parameter Block:



Byte Offset

Length (bytes)

Description


0x24

1

Physical drive number (0x00 for (first) removable media, 0x80 for (first) hard disk). Sometimes dynamically fixed up by prior bootstrap loader in order to force boot sector code to load next bootstrap loader from alternative physical disk.


0x25

1

Reserved; in boot code used as INT 13h head high byte for the 16-bits word at 0x24, in Windows NT used as CHKDSK flags (1: dirty, 2 bad sectors).^[27]


0x26

1

Extended boot signature. (Should be 0x29^[25] to indicate that an EBPB 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

Volume ID (serial number)


0x2B

11

Volume Label, padded with blanks (0x20), e.g., "NO␠NAME␠␠␠␠"


0x36

8

File system type, padded with blanks (0x20), e.g. "FAT12␠␠␠", "FAT16␠␠␠", "FAT32␠␠␠"
This entry is for display purposes only and must not be used by the operating system to identify the type of the filesystem.



0x3E

448

Operating system boot code; does not belong to the Extended BIOS Parameter Block


0x1FE

2

Boot sector signature 0x55 0xAA^[8]

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).
In essence FAT32 inserts 28 bytes, followed by the remaining 26 EBPB bytes as shown above for FAT12 and FAT16:



Byte Offset

Length (bytes)

Description


0x24

4

Logical sectors per file allocation table


0x28

2

Mirroring flags (4 low bits = active FAT number minus 1, if high bit set)


0x2A

2

Version (defined as 0)


0x2C

4

Cluster number of root directory start, typically 2 (first cluster^[12]) if it contains no bad sector.


0x30

2

Logical sector number of FS Information Sector, typically 1, i.e., the second of the three FAT32 boot sectors.


0x32

2

First logical sector number of a copy of the three FAT32 boot sectors, typically 6.^[8]


0x34

12

Reserved (must be 0)


0x40

1

Cf. 0x24 for FAT12/FAT16 (Physical Drive Number)


0x41

1

Cf. 0x25 for FAT12/FAT16


0x42

1

Cf. 0x26 for FAT12/FAT16 (Extended boot signature)


0x43

4

Cf. 0x27 for FAT12/FAT16 (Volume ID)


0x47

11

Cf. 0x2B for FAT12/FAT16 (Volume Label)


0x52

8

Cf. 0x36 for FAT12/FAT16 (File system type)


0x5A

420

Operating system boot code; does not belong to the Extended BIOS Parameter Block


0x1FE

2

Boot sector signature 0x55 0xAA

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^[28] 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

12

Reserved (byte values are 0x00)


0x1FC

4

FS information sector signature (0x00 0x00 0x55 0xAA)^[8]

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 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 4 bits (if FAT12), 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.^[26]
Because the first two FAT entries store special values, there is no cluster 0 or 1. The first cluster (after the root directory if FAT12/FAT16) is cluster 2.^[12]
FAT entry values:



FAT12

FAT16

FAT32

Description


0x000

0x0000

0x00000000

Free Cluster: also used as parent directory starting cluster in ".." entries for subdirectories of the root directory (FAT12/FAT16)


0x001

0x0001

0x00000001

Reserved, do not use


0x002-0xFEF

0x0002-0xFFEF

0x00000002-0x0FFFFFEF

Used cluster; value points to next cluster


0xFF0-0xFF5

0xFFF0-0xFFF5

0x0FFFFFF0-0x0FFFFFF5

Reserved in some contexts^[10] or also used^[2]^[8]^[9]


0xFF6

0xFFF6

0x0FFFFFF6

Reserved; do not use^[2]^[8]^[9]^[25]


0xFF7

0xFFF7

0x0FFFFFF7

Bad sector in cluster or reserved cluster


0xFF8-0xFFF

0xFFF8-0xFFFF

0x0FFFFFF8-0x0FFFFFFF

Last cluster in file (EOC)

Despite its name 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. A standard conformant FAT32 filesystem driver or maintenance tool should not rely on the upper 4 bits to be zero and 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. 
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 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 last modification, 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.
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 Current Directory Structure under MS-DOS/PC DOS limits the absolute path of a directory to 66 characters (including the drive letter, but excluding the zero delimiter), thereby limiting the maximum supported depth of subdirectories to 32, whatever occurs earlier. Concurrent DOS, Multiuser DOS and DR DOS 3.31 - 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.
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 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 and RMDIR/RD under DR-DOS which accept single arguments and therefore allow spaces to be entered.

! # $ % & ' ( ) - @ ^ _ ` { } ~ 
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
Value 127 (DEL)

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. The operating system will strip off one or two 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.)
The @-character is used for filelists by many DR-DOS, PalmDOS, Novell DOS, OpenDOS and Multiuser DOS, System Manager and REAL/32 commands as well as by 4DOS and may therefore sometimes be difficult to use in filenames.
Under Multiuser DOS and REAL/32, the exclamation mark (!) is not a valid filename character since it is used to separate multiple commands in a single command line.
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 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:



Value

Description


0x00

Entry is available and no subsequent entry is in use.


0x05

Initial character is actually 0xE5. Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, 0x05 is also used for deleted files for as long as they are still pending for possible undeletion under DELWATCH. Once they are removed from the deletion tracking queue, the first character of an erased file is replaced by 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. See also: 0x05.



0x08

3

Short file extension (padded with spaces)


0x0B

1

File Attributes


Bit

Mask

Description


0

0x01

Read Only. If this bit is set, the operating system will now allow a file to be opened for modification. Deliberately setting this bit for files which will not be written too (executables, shared libraries and data files) may help avoid problems with concurrent file access in multi-user or multi-tasking environments with applications not specifically designed to work in such environments.


1

0x02

Hidden. Hides files or directories from normal directory views. Under DR DOS 3.31 and higher, under PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, REAL/32, password protected files also have the hidden attribute set. Password-aware operating systems should not hide password-protected files from directory views, even if this bit may be set. The password protection mechanism does not depend on the hidden attribute being set up to including DR-DOS 7.03, but if the hidden attribute is set, it must not be cleared for any password-protected files.


2

0x04

System. Indicates that the file belongs to the system and must not be physically moved (f.e. during defragmentation), because it may be referenced to using absolute addressing bypassing the filesystem (boot loaders, kernel images, swap files, extended attributes, etc.).


3

0x08

Volume Label. Indicates an optional directory volume label, normally only residing in a volume's root directory. If this volume label is not present, some systems may fall back to display the partition volume label instead, if a EBPB is present in the boot sector (not present with some non-bootable block device drivers, and possibly not writeable with boot sector write protection). Even if this volume label is present, partitioning tools like FDISK may display the partition volume label instead. The entry occupies a directory entry but has no file associated with it. Volume labels have a filesize entry of zero.


4

0x10

Subdirectory. Indicates that the cluster-chain associated with this entry gets interpreted as subdirectory instead of as a file. Subdirectories have a filesize entry of zero.


5

0x20

Archive. Typically set by the operating system as soon as the file is created or modified to mark the file as "dirty", and reset by backup software once the file has been backed up to indicate "pure" state.


6

0x40

Device (internal use only, never found on disk), must not be changed by disk tools.


7

0x80

Reserved, must not be changed by disk tools.

Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, the volume attribute is set for deleted files for as long as they are still pending for possible undeletion under DELWATCH.
An attribute combination of 0x0F is used to designate a VFAT long file name entry since MS-DOS 7.0.



0x0C

1

Reserved; bits 3 and 4 are used by NT and later versions to encode case information (see below); otherwise 0^[29] Some versions of DR-DOS 7.0x use some other of these bits for various purposes. The value must not be changed by disk tools.


0x0D

1

Create time, fine resolution: 10ms units, values from 0 to 199 (since DOS 7 with VFAT LFN). (Also used to store the first character of a deleted file under Novell DOS, OpenDOS and DR-DOS 7.02 and higher. A value of 0xE5 (229), as set by DELPURGE, will prohibit undeletion by UNDELETE, a value of 0x00 will allow conventional undeletion asking the user for the missing first filename character. 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

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)

The seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0d.
Under DR DOS 3.31 and higher, a non-zero value indicates a password protected file, see below.



0x10

2

Create date (since DOS 7.0 with VFAT). 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–12)


4-0

Day (1–31)

With DELWATCH 2 under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry is used to store the last modified time stamp for deleted files and directories still in the deletion tracking queue. The newer usage for the creation time is not conflictive because the creation time is no longer important for deleted files. (FlexOS stores a record size in this entry.)



0x12

2

Last access date (since DOS 7.0 with VFAT if ACCDATE enabled); see offset 0x10 for description.
Multiuser DOS, FlexOS and some issues of DR-DOS use this field to store owner IDs, see below.
With DELWATCH 2 under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry is used to store the last modified date stamp for deleted files and directories still in the deletion tracking queue.
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. 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

EA-Index (used by OS/2 and NT) in FAT12 and FAT16, high 2 bytes of first cluster number in FAT32
Bitmask of world/group/owner file read/write/delete/execute protection for password protected files or directories under DR DOS 3.31 and higher, including PalmDOS, Novell DOS and OpenDOS, and under FlexOS, Multiuser DOS and REAL/32. Execute bit only under FlexOS (treated as Read on other systems), Group/Owner classes maintained also in single-user environments, but evaluated only with multi-user security loaded. (CP/M and DOS Plus store attributes F1-F4 here.)



0x16

2

Last modified time; see offset 0x0e for description.
Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion time of deleted files or directories under DELWATCH 2. The last modified time stamp is copied to 0x10 for possible later restoration.



0x18

2

Last modified date; see offset 0x10 for description.
Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion date of deleted files or directories under DELWATCH 2. The last modified date stamp is copied to 0x12 for possible later restoration.



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 FAT12/FAT16 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.

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. This method is very similar to the DELWATCH method to utilize the volume attribute to hide deleted files for possible future undeletion since DR DOS 6.0 (1991) and higher.
Older versions of 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.^[29]
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:



Byte Offset

Length (bytes)

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 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.^[30]

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 Offset

Length (bytes)

System

Description


0x0C

2

RISC OS

File type, 0x000–0xFFF


0x0C

4

Petrov DOSFS

File load address


0x10

4

Petrov DOSFS

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 FlexOS

Encrypted file password


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.0 and FlexOS

File owner ID


0x14

2

DR-DOS and FlexOS

File permissions bitmap (execute permissions are only used by FlexOS):


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

Size limits

The FAT12, FAT16 (Including BigFAT), 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 KB) 
FAT16 minimum : 1 sector per cluster × 4,085 clusters = 2,091,520 bytes ( 2,043 KB) 
FAT32 minimum : 1 sector per cluster × 65,525 clusters = 33,548,800 bytes (32,763 KB) 

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

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

FAT32 maximum : 8 sectors per cluster × 268,435,444 clusters = 1,099,511,578,624 bytes (≈1,024 GB) 
FAT32 maximum : 16 sectors per cluster × 268,173,557 clusters = 2,196,877,778,944 bytes (≈2,046 GB) 
[FAT32 maximum : 32 sectors per cluster × 134,152,181 clusters = 2,197,949,333,504 bytes (≈2,047 GB)]
[FAT32 maximum : 64 sectors per cluster × 67,092,469 clusters = 2,198,486,024,192 bytes (≈2,047 GB)]
[FAT32 maximum : 128 sectors per cluster × 33,550,325 clusters = 2,198,754,099,200 bytes (≈2,047 GB)]

Legend: 268435444+3 is hex. 0FFF FFF7, because FAT32 version 0 uses only 28 bits in the 32bit cluster numbers, cluster numbers hex. 0FFF FFF7 up to 0FFF FFFF flag bad clusters or the end of a file, cluster number 0 flags a free cluster, and cluster number 1 is not used.^[12] Likewise 65524+3 is hex. FFF7 for FAT16, and 4084+3 is hex. FF7 for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 (hex. 01), the biggest value is 128 (hex. 80). Lines in square brackets indicate the unusual cluster size 128, and for FAT32 the bigger than necessary cluster sizes 32 or 64.^[17]
Because each FAT32 entry occupies 32bits (4 bytes) the maximal number of clusters (268435444) requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is hex. 200000, and storing this value needs more than two bytes. Therefore FAT32 introduced a new 32bit value in the FAT32 boot sector immediately following the 32bit value for the total number of sectors introduced in the "BigFAT" variant of FAT16.
The boot record extensions introduced with DOS 4.0 start with a magic 40 (hex. 28) or 41 (hex. 29). 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 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 "BigFAT" 32bit number of hidden sectors, this leaves three bytes for the (on a RAM disk unused) boot code and the magic hex. 55AA 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 hex. 80 (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 ECMA 107^[2] 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 (hex. FF6, FAT12) and later 65526 (hex. FFF6, FAT16) for future standardization.
Microsoft's EFI FAT32 specification^[8] 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 entries for cluster numbers 0 and 1 at the begin of the FAT contain the media descriptor and end at a byte boundary even for FAT12, e.g., hex. F9FFFF for media descriptor hex. F9. The first data cluster is 2,^[12] and consequently the last cluster MAX gets number MAX+1. This results in data cluster numbers 2...4085 (hex. FF5) for FAT12, 2...65525 (hex. FFF5) for FAT16, and 2...268435445 (hex. 0FFF FFF5) for FAT32.

The only available values reserved for future standardization are therefore hex. FF6 (FAT12) and hex. FFF6 (FAT16). As noted below "less than 4085" is also used for Linux implemementations,^[9] or as Microsoft's FAT specification puts it:^[8]

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.^[31] 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 entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less (such as with DOS) for which FAT has been designed and optimized originally.
With the introduction of FAT32, long seek 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.^[32] Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special filesystem 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 KB, 32 KB, 64 KB) forced by larger FAT partitions, internal fragmentation in form of disk space waste by file slack due to cluster overhang (as files are rarely exact multiples of cluster size) starts to be a problem as well, especially when there are a great many small files.
Various optimizations and tweaks to the implementation of FAT filesystem drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the filesystem'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 filesystems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.
Since DOS 3.3 the operating system provides means to improve the performance of file operatings 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. Special care must be taken when using such mechanisms in conjunction with disk defragmentation software, bypassing the file system.
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 alot of random data at the end.
Other high-level mechanisms may read in and process larger amounts or even the complete FAT either systematically on startup or on demand when needed and thereby dynamically build up in-memory tree representations of the disk structures different from the on-disk FAT structure. 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 become 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 mechanisms.
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.

Third-party support

Further information: [[:FAT filesystem and Linux]]

Due to the widespread use of FAT formatted media since its introduction many operating systems have provided support for FAT and subsequently VFAT and FAT32 through official or third-party file system handlers. For example, Linux, FreeBSD, BeOS and JNode provide inbuilt support for FAT. 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 “--linux-.---”. UMSDOS fell into disuse after VFAT was released and it is not enabled by default in Linux kernels from version 2.5.7 onwards.^[33] Mac OS 9 and Mac OS X also support FAT file systems on volumes other than the boot disk. AmigaOS 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.^[34]

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).^[35]
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").

Uses

FAT is 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. 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 both in Windows and Linux environments.
The FAT file system is technically simple yet robust. It offers reasonable performance even in light-weight implementations and is therefore widely adopted and 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.

Licensing

 This section possibly contains original research. Please improve it by verifying the claims made and adding inline citations. Statements consisting only of original research should be removed.  (December 2011) (Learn how and when to remove this message)

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^[36] 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.^[37]
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 5,745,902: 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 5,579,517: 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^[38] on 2004-09-14, due to prior disclosure^[39] of the claimed techniques in patents U.S. patent 5,307,494 and U.S. patent 5,367,671. This decision was later overturned by the Patent Office on 2006-01-10.
U.S. patent 5,758,352: 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".^[40]^[41] This decision was also later overturned by the Patent Office on 2006-01-10.
U.S. patent 6,286,013: 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^[who?] 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 EFI FAT32 specification^[8] 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 5,367,671: 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.^[42]
On 2004-09-30 the USPTO rejected all claims of U.S. patent 5,579,517, 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 5,758,352 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.^[43]

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.^[44] 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.^[45]
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.^[46] They also submitted a complaint to the ITC.^[47]
Developers of open source software have designed methods intended to circumvent Microsoft's patents.^[48]

See also

Comparison of file systems
Drive letter assignment
List of file systems
Transaction-Safe FAT File System

References



^ ^a ^b "File Systems". Microsoft TechNet. 2001. Retrieved 2011-07-31.

^ ^a ^b ^c ^d ^e ^f "Volume and File Structure of Disk Cartridges for Information Interchange". Standard ECMA-107 (2nd ed.). ECMA. 1995. Retrieved 2011-07-30.

^ "Volume and file structure of disk cartridges for information interchange". ISO/IEC 9293:1994. ISO catalogue. 1994. Retrieved 2011-07-30.

^ Reynolds; et al. (1998-05-26). "Common name space for long and short filenames". US Patent 5758352. Retrieved 2011-07-30. {{cite web}}: Explicit use of et al. in: |author= (help)

^ Duncan, Ray, 1988. The MS-DOS Encyclopedia, Microsoft Press. ISBN 1-55615-049-0.

^ Wallace & Erickson, 1992. Hard Drive, John Wiley & Sons. ISBN 0-471-56886-4.

^ Tim Paterson (2007-09-30). "Design of DOS". DosMan Drivel. Retrieved 2011-07-04.

^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k "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 Andries Brouwer. "FAT Under Linux".

^ ^a ^b Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157.

^ Brian Jenkinson, Sammes, A. J. (2000). Forensic Computing: A Practitioner's Guide (Practitioner Series). Berlin: Springer. p. 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.{{cite book}}:  CS1 maint: multiple names: authors list (link)

^ ^a ^b ^c ^d ^e 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.

^ Microsoft Knowledge Base article: "MS-DOS Partitioning Summary"

^ "Dskprobe Overview: Data Recovery". Microsoft TechNet. 2003-03-28. Retrieved 2011-08-03.

^ "Errors Creating Files or Folders in the Root Directory". Microsoft Help and Support. December 16, 2004. Retrieved 2006-10-14.

^ "mkdosfs man page".

^ ^a ^b "Limitations of FAT32 File System". Microsoft Knowledge Base. 2007-03-26. Retrieved 2011-08-21. Clusters cannot be 64 kilobytes (KB) or larger

^ "Limitations of the FAT32 File System in Windows XP". Microsoft Knowledge Base. 2007-12-01. Retrieved 2011-08-21.

^ "FATX Specification". free60 wiki. Retrieved 2011-08-16.

^ "Xbox Partitioning and Filesystem Details". Xbox-Linux project.

^ "Differences between Xbox FATX and MS-DOS FAT". Xbox-Linux project.

^ 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.

^ Matthias Paul (2004-08-25). "NOVOLTRK.REG". www.drdos.org. Retrieved 2011-12-17.

^ ^a ^b ^c Microsoft MS-DOS Programmer's Reference : version 5.0. Microsoft press. 1991. ISBN 1-55615-329-5.

^ ^a ^b Andries Brouwer (2002-09-20). "The FAT filesystem". Retrieved 2011-10-16.

^ ^a ^b "Detailed Explanation of FAT Boot Sector". Microsoft Knowledge Base. 2003-12-06. Retrieved 2011-10-16.

^ "Detailed Explanation of FAT Boot Sector". DEW Associates Corporation. 2002. Retrieved 2011-10-16.

^ ^a ^b vinDaci (1998-01-06). "Long Filename Specification". Retrieved 2007-03-13.

^ "mount(8): mount file system". Linux man page.

^ 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 'scan' errors; e.g., "Ray" is the author's correct name; not 'Roy' as text shows.]

^ Chen, Raymond (2006). Microsoft TechNet: A Brief and Incomplete History of FAT32. TechNet Magazine July 2006.

^ "Release notes for v2.5.7". The Linux Kernel archives. 2002-03-12. Retrieved 2006-10-14.

^ "fat32format". Ridgecrop Consultants Ltd. Retrieved 2011-09-06.

^ Bob Eager (2000-10-28). "Implementation of extended attributes on the FAT file system". Tavi OS/2 pages. Retrieved 2006-10-14.

^ Microsoft.com

^ title = FAT%20File%20System "FAT File System". Intellectual Property Licensing. Microsoft. {{cite web}}: Check |url= value (help); Missing pipe in: |url= (help)

^ "At PUBPAT's request, patent office rejects Microsoft's FAT patent: Government Relies Heavily on Evidence Submitted by PUBPAT". Public Patent Foundation. 2004-09-30. Retrieved 2006-10-14.

^ Ina Fried (2004-09-30). "Microsoft FAT patent falls flat". CNET News. Retrieved 2006-10-14.

^ Andrew Orlowski (2005-10-05). "Microsoft FAT patent rejected — again". The Register. Retrieved 2006-10-14.

^ "Patent Office rejects two Microsoft FAT patents". out-law.com. 2005-06-10. Retrieved 2006-10-14.

^ Andrew Orlowski (2004-06-14). "Microsoft's war on GPL dealt patent setback". The Register. Retrieved 2006-10-14.

^ Anne Broache (2006-01-10). "Microsoft's file system patent upheld". CNET News. 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.

^ "Micrsoft 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.

^ Brown, Eric (2009-07-02). "Can FAT patch avoid Microsoft lawsuits?". DesktopLinux.Com. Retrieved 2009-08-23.

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 Filesystems (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 Filesystem implementation for *nix: Includes libfat libraries and fusefat , a FUSE filesystem 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 GB 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 not longer available on Microsoft website.
Visual Layout of a FAT16 drive
Understand the Master Boot Record of FAT16


v
t
e
File systems

Comparison of file systems
distributed
Unix filesystem
Disk and
non-rotating 

ADFS
AdvFS
Amiga FFS
Amiga OFS
APFS
AthFS
bcachefs
BFS
Be File System
Boot File System
Byte File System (z/VM)
Btrfs
CVFS
CXFS
DFS
EFS
Encrypting File System
Extent File System
Episode
ext
ext2
ext3
ext3cow
ext4
FAT
exFAT
Files-11
Fossil
GPFS
HAMMER
HAMMER2
HFS (Classic Mac OS)
HFS (MVS)
HFS+
HPFS
HTFS
JFS
LFS
MFS
Macintosh File System
TiVo Media File System
MINIX
NetWare File System
Next3
NILFS
NILFS2
NSS
NTFS
OneFS
OpenZFS
PFS
QFS
QNX4FS
ReFS
ReiserFS
Reiser4
Reliance
Reliance Nitro
RFS
SFS
Shared File System (VM)
Smart File System
SNFS
Soup (Apple)
Tux3
UBIFS
UFS/UFS2
soft updates
WAPBL
VxFS
WAFL
Xiafs
XFS
Xsan
zFS (z/OS)
ZFS (Sun)
Optical disc 
HSF
ISO 9660
ISO 13490
UDF
Flash memory and SSD 
APFS
FAT
exFAT
TFAT
EROFS
F2FS
JFS
NVFS
  
host-side wear leveling 
CHFS
JFFS
JFFS2
LogFS
NILFS
NILFS2
YAFFS
UBIFS

Distributed parallel 
BeeGFS
Ceph
CXFS
GFS2
Google File System
OCFS2
OrangeFS
PVFS
QFS
Xsan
more...
NAS 
9P
AFS (OpenAFS)
AFP
Coda
DFS
Google File System
GPFS
Lustre
NCP
NFS
POHMELFS
Hadoop
SMB (CIFS)
SSHFS
more...
Specialized 

Aufs
AXFS
Boot File System
CDfs
Compact Disc File System
cramfs
Davfs2
EROFS
FTPFS
FUSE
Lnfs
LTFS
NOVA
MVFS
SquashFS
UMSDOS
OverlayFS
UnionFS
Pseudo 
configfs
devfs
debugfs
kernfs
procfs
specfs
sysfs
tmpfs
WinFS
Encrypted 
eCryptfs
EncFS
EFS
Rubberhose
SSHFS
ZFS
Types 
Clustered
Global
Grid
Self-certifying
Flash
Journaling
Log-structured
Object
Record-oriented
Semantic
Steganographic
Synthetic
Versioning
Features 

Case preservation
Copy-on-write
Data deduplication
Data scrubbing
Execute in place
Extent
File attribute
Extended file attributes
File change log
Fork
Links
Hard
Symbolic
Access control 
Access-control list
Filesystem-level encryption
Permissions
Modes
Sticky bit
Interfaces 
File manager
File system API
Installable File System
Virtual file system
Lists 
Cryptographic
Default
Log-structured
Layouts 
Master Boot Record
GUID Partition Table
Apple Partition Map


v
t
e
Microsoft Windows components

APIs
Architecture
9x
NT
Booting process
Games
Management
tools 
App Installer
Command Prompt
Control Panel
Device Manager
Disk Cleanup
Drive Optimizer
Driver Verifier
DirectX Diagnostic Tool
Event Viewer
IExpress
Management Console
Netsh
Performance Monitor
Recovery Console
Resource Monitor
Settings
Sysprep
System Configuration
System File Checker
System Information
System Policy Editor
System Restore
Task Manager
Windows Error Reporting
Windows Ink
Windows Installer
PowerShell
Windows Update
Windows Insider
WinRE
WMI
Apps 
3D Viewer
Clock
Calculator
Calendar
Camera
Character Map
Clipchamp
Cortana
Edge
Fax and Scan
Feedback Hub
Get Help
Magnifier
Mail
Maps
Messaging
Media Player
2022
Movies & TV
Mobility Center
Money
Narrator
Notepad
OneDrive
OneNote
Paint
Paint 3D
People
Phone Link
Photos
Quick Assist
Remote Desktop Connection
Snipping Tool
Speech Recognition
Skype
Sports
Start
Sticky Notes
Store
Tips
Voice Recorder
Weather
WordPad
Xbox
Shell 
Action Center
Aero
AutoPlay
AutoRun
ClearType
Explorer
Search
Indexing Service
IFilter
Saved search
Namespace
Special folder
Start menu
Taskbar
Task View
Windows Spotlight
Windows XP visual styles
Services 
Service Control Manager
BITS
CLFS
Multimedia Class Scheduler
Shadow Copy
Task Scheduler
Error Reporting
Wireless Zero Configuration
File systems 
CDFS
DFS
exFAT
IFS
FAT
NTFS
Hard link
links
Mount Point
Reparse point
TxF
EFS
ReFS
UDF
Server 
Active Directory
Domains
DNS
Group Policy
Roaming user profiles
Folder redirection
Distributed Transaction Coordinator
MSMQ
Windows Media Services
Active DRM Services
IIS
WSUS
SharePoint
Network Access Protection
PWS
DFS Replication
Print Services for UNIX
Remote Desktop Services
Remote Differential Compression
Remote Installation Services
Windows Deployment Services
System Resource Manager
Hyper-V
Server Core
Architecture 
Boot Manager
Console
CSRSS
Desktop Window Manager
Portable Executable
EXE
DLL
Enhanced Write Filter
Graphics Device Interface
Hardware Abstraction Layer
I/O request packet
Imaging Format
Kernel Transaction Manager
Library files
Logical Disk Manager
LSASS
MinWin
NTLDR
Ntoskrnl.exe
Object Manager
Open XML Paper Specification
Registry
Resource Protection
Security Account Manager
Server Message Block
Shadow Copy
SMSS
System Idle Process
USER
WHEA
Winlogon
WinUSB
Security 
Security and Maintenance
AppLocker
BitLocker
Credential Guard
Data Execution Prevention
Defender
Family features
Kernel Patch Protection
Mandatory Integrity Control
Protected Media Path
User Account Control
User Interface Privilege Isolation
Windows Firewall
Compatibility 
COMMAND.COM
Windows Subsystem for Linux
WoW64
API 
Active Scripting
WSH
VBScript
JScript
COM
ActiveX
ActiveX Document
COM Structured storage
DCOM
OLE
OLE Automation
Transaction Server
DirectX
Native
.NET
Universal Windows Platform
WinAPI
Windows Mixed Reality
Windows Runtime
WinUSB
Games 
Solitaire Collection
Surf
Discontinued 
Games 
3D Pinball
Chess Titans
FreeCell
Hearts
InkBall
Hold 'Em
Purble Place
Spider Solitaire
Solitaire
Tinker
Apps 
ActiveMovie
Anytime Upgrade
Address Book
Backup and Restore
Cardfile
CardSpace
CD Player
Chat
Contacts
Desktop Gadgets
Diagnostics
DriveSpace
DVD Maker
Easy Transfer
Fax
Food & Drink
Groove Music
Help and Support Center
Health & Fitness
HyperTerminal
Imaging
Internet Explorer
Journal
Make Compatible
Media Center
Meeting Space
Messaging
Messenger
Mobile Device Center
Movie Maker
MSN Dial-up
NetMeeting
NTBackup
Outlook Express
Pay
Phone Companion
Photo Gallery
Photo Viewer
Program Manager
Steps Recorder
Syskey
Travel
WinHelp
Write
Others 
Games for Windows
ScanDisk
File Protection
Media Control Interface
MS-DOS 7
Next-Generation Secure Computing Base
POSIX subsystem
HPFS
Interix
Video for Windows
Virtual DOS machine
Windows on Windows
Windows SideShow
Windows Services for UNIX
Windows System Assessment Tool
Windows To Go
WinFS
Spun off to
Microsoft Store 
DVD Player
File Manager
Hover!
Mahjong
Minesweeper

 Category
 List


v
t
e
Standards of Ecma International
Application interfaces 
ANSI escape code
APIW
Common Language Infrastructure
Office Open XML
OpenXPS
File systems (tape) 
Advanced Intelligent Tape
DDS
DLT
Super DLT
Linear Tape-Open (Ultrium-1)
VXA
File systems (disk) 
CD-ROM
CD File System (CDFS)
FAT
FAT12
FAT16
FAT16B
FD
UDF
Ultra Density Optical
Universal Media Disc
Holographic Versatile Disc
Graphics 
Universal 3D
Programming languages 
C++/CLI
C#
Eiffel
JavaScript (E4X, ECMAScript)
Dart
Minimal BASIC
Full BASIC
Radio link interfaces 
NFC
UWB
Other 
ECMA-35
JSON
List of Ecma standards (1961 – present)

Template:Link GA

[GB4-1] "File Systems". Microsoft TechNet. 2001. Retrieved 2011-07-31.

[Ecma-107-2] ^ ^a ^b ^c ^d ^e ^f "Volume and File Structure of Disk Cartridges for Information Interchange". Standard ECMA-107 (2nd ed.). ECMA. 1995. Retrieved 2011-07-30.

[3] "Volume and file structure of disk cartridges for information interchange". ISO/IEC 9293:1994. ISO catalogue. 1994. Retrieved 2011-07-30.

[4] Reynolds; et al. (1998-05-26). "Common name space for long and short filenames". US Patent 5758352. Retrieved 2011-07-30. {{cite web}}: Explicit use of et al. in: |author= (help)

[5] Duncan, Ray, 1988. The MS-DOS Encyclopedia, Microsoft Press. ISBN 1-55615-049-0.

[6] Wallace & Erickson, 1992. Hard Drive, John Wiley & Sons. ISBN 0-471-56886-4.

[7] Tim Paterson (2007-09-30). "Design of DOS". DosMan Drivel. Retrieved 2011-07-04.

[efi-8] ^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k "Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format". Microsoft. 2000-12-06. Retrieved 2011-07-03.

[max4084-9] Andries Brouwer. "FAT Under Linux".

[Norton2-10] Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157.

[11] Brian Jenkinson, Sammes, A. J. (2000). Forensic Computing: A Practitioner's Guide (Practitioner Series). Berlin: Springer. p. 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.{{cite book}}: CS1 maint: multiple names: authors list (link)

[two-12] 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.

[13] Microsoft Knowledge Base article: "MS-DOS Partitioning Summary"

[14] "Dskprobe Overview: Data Recovery". Microsoft TechNet. 2003-03-28. Retrieved 2011-08-03.

[15] "Errors Creating Files or Folders in the Root Directory". Microsoft Help and Support. December 16, 2004. Retrieved 2006-10-14.

[16] "mkdosfs man page".

[kb184006-17] "Limitations of FAT32 File System". Microsoft Knowledge Base. 2007-03-26. Retrieved 2011-08-21. Clusters cannot be 64 kilobytes (KB) or larger

[18] "Limitations of the FAT32 File System in Windows XP". Microsoft Knowledge Base. 2007-12-01. Retrieved 2011-08-21.

[19] "FATX Specification". free60 wiki. Retrieved 2011-08-16.

[20] "Xbox Partitioning and Filesystem Details". Xbox-Linux project.

[21] "Differences between Xbox FATX and MS-DOS FAT". Xbox-Linux project.

[Paul_2002_OEM-22] Matthias Paul (2002-02-20). "Need DOS 6.22 (Not OEM)". alt.msdos.programmer. Retrieved 2006-10-14.

[23] Wally Bass (1994-02-14). "Cluster Size". comp.os.msdos.programmer. Retrieved 2006-10-14.

[Paul_2004_OEM-24] Matthias Paul (2004-08-25). "NOVOLTRK.REG". www.drdos.org. Retrieved 2011-12-17.

[msdosref-25] Microsoft MS-DOS Programmer's Reference : version 5.0. Microsoft press. 1991. ISBN 1-55615-329-5.

[AB-26] Andries Brouwer (2002-09-20). "The FAT filesystem". Retrieved 2011-10-16.

[KB140418-27] "Detailed Explanation of FAT Boot Sector". Microsoft Knowledge Base. 2003-12-06. Retrieved 2011-10-16.

[28] "Detailed Explanation of FAT Boot Sector". DEW Associates Corporation. 2002. Retrieved 2011-10-16.

[LongSpec-29] vinDaci (1998-01-06). "Long Filename Specification". Retrieved 2007-03-13.

[30] "mount(8): mount file system". Linux man page.

[dgaiotnhpfs-31] 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 'scan' errors; e.g., "Ray" is the author's correct name; not 'Roy' as text shows.]

[TechNet_on_FAT32-32] Chen, Raymond (2006). Microsoft TechNet: A Brief and Incomplete History of FAT32. TechNet Magazine July 2006.

[33] "Release notes for v2.5.7". The Linux Kernel archives. 2002-03-12. Retrieved 2006-10-14.

[34] "fat32format". Ridgecrop Consultants Ltd. Retrieved 2011-09-06.

[35] Bob Eager (2000-10-28). "Implementation of extended attributes on the FAT file system". Tavi OS/2 pages. Retrieved 2006-10-14.

[36] Microsoft.com

[37] title = FAT%20File%20System "FAT File System". Intellectual Property Licensing. Microsoft. {{cite web}}: Check |url= value (help); Missing pipe in: |url= (help)

[38] "At PUBPAT's request, patent office rejects Microsoft's FAT patent: Government Relies Heavily on Evidence Submitted by PUBPAT". Public Patent Foundation. 2004-09-30. Retrieved 2006-10-14.

[39] Ina Fried (2004-09-30). "Microsoft FAT patent falls flat". CNET News. Retrieved 2006-10-14.

[40] Andrew Orlowski (2005-10-05). "Microsoft FAT patent rejected — again". The Register. Retrieved 2006-10-14.

[41] "Patent Office rejects two Microsoft FAT patents". out-law.com. 2005-06-10. Retrieved 2006-10-14.

[42] Andrew Orlowski (2004-06-14). "Microsoft's war on GPL dealt patent setback". The Register. Retrieved 2006-10-14.

[43] Anne Broache (2006-01-10). "Microsoft's file system patent upheld". CNET News. Retrieved 2006-10-14.

[44] Paul, Ryan (2009-02-25). "Microsoft suit over FAT patents could open OSS Pandora's Box". arstechnica.com. Retrieved 2009-02-28.

[45] Fried, Ina (2009-03-30). "Microsoft, TomTom settle patent dispute". cnet.com. Retrieved 2009-08-22.

[46] "Micrsoft Motorola Patent Suit". 2010-10-01. Retrieved 2010-10-02.

[47] Protalinski, Emil (2010-10-01). "Microsoft sues Motorola, citing Android patent infringement". arstechnica.com. Retrieved 2010-10-02.

[48] Brown, Eric (2009-07-02). "Can FAT patch avoid Microsoft lawsuits?". DesktopLinux.Com. Retrieved 2009-08-23.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

@@ Line 952: / Line 952: @@
 === Fragmentation ===
-The FAT file system does not contain mechanisms which prevent newly written files from becoming scattered across the partition.<ref name="dgaiotnhpfs">{{ cite web | url = http://cd.textfiles.com/megademo2/INFO/OS2_HPFS.TXT | title = Design goals and implementation of the new High Performance File System | author = Duncan, Ray | year = 1989 | publisher = Microsoft Systems Journal | volume=4 | issue=5 }} [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.]</ref> Other file systems, e.g., [[HPFS]], use [[free space bitmap]]s that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in [[Unix]] file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.
+The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition.<ref name="dgaiotnhpfs">{{ cite web | url = http://cd.textfiles.com/megademo2/INFO/OS2_HPFS.TXT | title = Design goals and implementation of the new High Performance File System | author = Duncan, Ray | year = 1989 | publisher = Microsoft Systems Journal | volume=4 | issue=5 }} [NB. This particular text file has a number of 'scan' errors; e.g., "Ray" is the author's correct name; not 'Roy' as text shows.]</ref> On volumes, where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time.
+While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of [[Fragmentation (computing)|fragmentation]], as it occurs with [[external fragmentation]], the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (with parts having to be loaded into memory first in particular on large volumes) and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive. Also, file operations will become slower with growing fragmentation as it takes increasingly longer for the operating system to find files or free clusters.
-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.<ref name="TechNet on FAT32">Chen, Raymond (2006). [http://www.microsoft.com/technet/technetmag/issues/2006/07/WindowsConfidential/ Microsoft TechNet: A Brief and Incomplete History of FAT32]. ''TechNet Magazine'' July 2006''.</ref> Displaying this line took longer and longer as the number of clusters increased.
+Other file systems, e.g. [[HPFS]] or [[exFAT]], use [[free space bitmap]]s that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in [[Unix]] file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.
-Some of the perceived problems with [[Fragmentation (computer)|fragmentation]] of FAT file systems result from limitations of the [[device driver]]s.
+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 entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less (such as with DOS) for which FAT has been designed and optimized originally.
-The single-tasking DOS and the traditionally single-tasking PC hard disk architecture ([[Native Command Queuing|only 1 outstanding input/output request at a time]], [[Programmed input/output|no DMA transfers]]) did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks.
+With the introduction of FAT32, long seek 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.<ref name="TechNet on FAT32">Chen, Raymond (2006). [http://www.microsoft.com/technet/technetmag/issues/2006/07/WindowsConfidential/ Microsoft TechNet: A Brief and Incomplete History of FAT32]. ''TechNet Magazine'' July 2006''.</ref> Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special filesystem information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-[[ATX]]-style PCs<!-- as on ATX-style PCs the former power-switch was replaced by a soft-button, which is under BIOS and OS control -->, on plain DOS systems<!-- as most DOS issues have no true "shutdown" command --> and some battery-powered consumer products.
-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.
+With the huge cluster sizes (16 KB, 32 KB, 64 KB) forced by larger FAT partitions, [[internal fragmentation]] in form of disk space waste by file slack due to [[cluster overhang]] (as files are rarely exact multiples of cluster size) starts to be a problem as well, especially when there are a great many small files.
-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.
+Various optimizations and tweaks to the implementation of FAT filesystem drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the filesystem'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 filesystems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.<!-- a low-performance read-only implementation of FAT12/FAT16/FAT32 can be done in as little as 512 bytes of code and 1 KB of data -->
-With the large cluster sizes, 4 or 8K, 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.
+Since DOS 3.3 the operating system provides means to improve the performance of file operatings with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC DOS)<!-- 48 bytes per entry --> or hash tables (DR-DOS)<!-- 2 bytes per entry -->, which can reduce file seek and open times significantly. Special care must be taken when using such mechanisms in conjunction with disk defragmentation software, bypassing the file system.
+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 alot of random data at the end.
+Other high-level mechanisms may read in and process larger amounts or even the complete FAT either systematically on startup or on demand when needed and thereby dynamically build up in-memory tree representations of the disk structures different from the on-disk FAT structure. This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background.
+Some of the perceived problems with [[Fragmentation (computer)|fragmentation]] of FAT file systems also result from performance limitations of the underlying block [[device driver]]s, which become more visible the lesser memory is available for sector buffering and track blocking/deblocking:
+While the single-tasking DOS had provisions for multi-sector reads and track blocking/deblocking, the operating system and the traditional PC hard disk architecture ([[Native Command Queuing|only one outstanding input/output request at a time]] and [[Programmed input/output|no DMA transfers]]) originally did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks. Such features became available later. Later DOS versions also provided built-in support for look-ahead sector buffering and came with dynamically loadable disk caching programs working on physical or logical sector level, often utilizing [[Expanded memory|EMS]] or [[Extended memory|XMS]] memory and sometimes providing adaptive caching mechanisms.
+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.
 === Third-party support ===