Wifedogging

This article may be too technical for most readers to understand. Please help improve this article to make it understandable to non-experts, without removing the technical details. The talk page may contain suggestions. (December 2011)

File Allocation Table (FAT) is the name of a computer file system architecture and a family of industry standard file systems utilizing it.

The FAT file system is technically relatively simple yet robust. It offers reasonably good 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 well-suited format for data exchange between computers and devices of almost any type and age from the early 1980s up to the present.

Originally designed in the late 1970s for use on floppy disks, it was soon adapted and used almost universally on hard disks throughout the DOS and Windows 9x eras for two decades. With the introduction of more powerful computers and operating systems, its use on hard drives has since started to decline, but it continues to be used on many computer systems.

Today, FAT file systems are still commonly found on floppy disks, solid-state memory cards, flash memory cards, and on many portable and embedded devices.

The name of the file system originates from the file system's prominent usage of an index table, the FAT, statically allocated at the time of formatting. The table contains entries for each cluster, a contiguous area of disk storage. Each entry contains either the number of the next cluster in the file, or else a marker indicating end of file, unused disk space, or special reserved areas of the disk. The root file directory of the disk contains the number of the first cluster; the operating system can then traverse the FAT table, looking up the cluster number of each successive part of the disk file as a cluster chain until the end of the file is reached.

As disk drives have evolved, the maximum number of clusters has significantly increased, and so the number of bits used to identify each cluster has grown. The successive major versions of the FAT format are named after the number of table element bits: 12 (FAT12), 16 (FAT16), and 32 (FAT32). Each of these variants is still in use. The FAT standard has also been expanded in other ways while generally preserving backward compatibility with existing software.

Overview

Uses

The FAT file system is 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 as well as some home computers and embedded systems. This makes it a useful format for solid-state memory cards and a convenient way to share data between operating systems.

FAT file systems are the default file system for removable media (with the exception of CDs and DVDs) and as such are commonly found on floppy disks, super-floppies, memory and flash memory cards or USB flash drives and are supported by most portable devices such as PDAs, digital cameras, camcorders, media players, or mobile phones. While FAT12 is omnipresent on floppy disks, FAT16 and FAT32 are typically found on the larger media.

FAT was also commonly used on hard disks throughout the DOS and Windows 9x eras, but its use on hard drives has declined since the introduction of Windows XP, which primarily uses the newer NTFS. FAT is still used in hard drives expected to be used by multiple operating systems, such as in shared Windows and Linux environments.

Due to the widespread use of FAT-formatted media, 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.

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.

For many purposes, the NTFS file system is superior to FAT in terms of features and reliability; its main drawbacks are the size overhead for small volumes and the very limited support by anything other than the NT-based versions of Windows, since the exact specification is a trade secret of Microsoft. The availability of NTFS-3G since mid-2006 has led to much improved NTFS support in Unix-like operating systems, considerably alleviating this concern. It is still not possible to use NTFS in DOS-like operating systems without third-party drivers, which in turn makes it difficult to use a DOS floppy for recovery purposes. Microsoft provided a recovery console to work around this issue, but for security reasons it severely limited what could be done through the Recovery Console by default. The movement of recovery utilities to boot CDs based on BartPE or Linux (with NTFS-3G) is finally eroding this drawback.

FAT has a long history (over three decades) of usage on desktops and portable computers, and it is frequently used in embedded solutions. It continues to be the most widespread file system worldwide.

For floppy disks, FAT has been standardized as ECMA-107 and ISO/IEC 9293:1994 (superseding ISO 9293:1987). These standards cover FAT12 and FAT16 with only short 8.3 filename support; long filenames with VFAT are partially patented.

Historical evolution

File system types

Original 8-bit FAT

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 used in a stand-alone version of Microsoft BASIC for the 8086 chip in 1979 and eventually in the M-DOS operating system. The Microsoft Disk BASIC version supported three FATs.

FAT12

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. Later in 1981 86-DOS evolved into Microsoft's MS-DOS and IBM PC DOS.

Originally designed as a file system for floppy disks, FAT12 used 12-bit entries for the cluster addresses in the FAT, which not only limited the maximum generally possible count of data clusters to 4078 (for data clusters 0x002 to 0xFEF; in C-notation for hexadecimal numbers) or in some controlled scenarios even up to 4084 (for data clusters 0x002 to 0xFF5), but made FAT manipulation tricky with the PC's 8-bit and 16-bit registers. (NB. While MS-DOS and PC DOS support up to 4084 data clusters on FAT12 volumes in general, cluster value 0xFF0 is treated as additional end-of-chain marker on any FAT12 volume since MS-DOS/PC DOS 3.3, therefore restricting the maximum practical number of data clusters to 4078 for compatibility purposes with these operating systems.)

The disk's size was stored and calculated as a 16-bit count of sectors, which limited the size to 32 MB for a logical sector size of 512 bytes. FAT12 was used by several manufacturers with different physical formats, but a typical floppy disk at the time was 5.25-inch (130 mm), single-sided, 40 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. (NB. The 32 MB limit was later circumvented using logical sectored FATs with logical sector sizes larger than 512 bytes in some OEM versions of MS-DOS 3.x and it was further lifted with DOS 3.31, which supported 32-bit sector numbers, but seldomly used due to the availability of FAT16B.)

By convention, all the control structures were organized to fit inside the first track, thus avoiding head movement during read and write operations, although this varied depending on the manufacturer and physical format of the disk. A limitation which was not addressed until much later (with FAT32) was that any bad sector in the control structures area, track 0, could prevent the disk from being usable. The DOS formatting tool rejected such disks completely. Bad sectors were allowed only in the file data area and were marked with the reserved value 0xFF7 in the FAT. They made the entire containing cluster unusable.

While 86-DOS supported three disk formats (250.25 KB, 500.5 KB and 1232 KB with media descriptor bytes 0xFF and 0xFE) on 8-inch (200 mm) floppy drives, IBM PC DOS 1.0, released with the original IBM Personal Computer in 1981, supported only a 8-sector floppy format with a formatted capacity of 160 KB (media descriptor byte 0xFE) for single-sided 5.25-inch floppy drives, and PC DOS 1.1 added support for a double-sided format with 320 KB (media descriptor byte 0xFF). PC DOS 2.0 introduced support for 9-sector floppy formats with 180 KB (media descriptor byte 0xFC) and 360 KB (media descriptor byte 0xFD).

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. At this time, DOS did not support a hierarchical file system, which was still acceptable, given that the number of files on a disk was typically not more than a few dozen.

The PC XT was the first PC with a hard drive from IBM, and PC DOS 2.0 supported that hard drive with FAT12 (media descriptor byte 0xF8). The fixed assumption of 8 sectors per clusters on hard disks practically limited the maximum partition size to 16 MB for 512 byte sectors and 4 KB clusters.

The BIOS Parameter Block (BPB) was introduced with PC DOS 2.0 as well, and this version also added read-only, archive, volume label, and directory attribute bits for hierarchical sub-directories.

MS-DOS 3.0 introduced support for high-density 1.2 MB 5.25-inch diskettes (media descriptor byte 0xF9), which notably had 15 sectors per track, hence more space for the FATs.

FAT12 remains in use on all common floppy disks, including 1.44 MB and later 2.88 MB disks (media descriptor byte 0xF0).

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. A partition type 0x04 indicates this form of FAT16 with less than 65536 sectors (less than 32 MB for sector size 512).

With the initial implementation of FAT16 not actually providing for larger partition sizes than FAT12, the early benefit of FAT16 was to enable the use of smaller clusters, making disk usage more efficient, particularly for 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. 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.

Logical sectored FAT

When hard disks grew larger and the FAT12 and FAT16 file system implementation in MS-DOS / PC DOS did not provide means to take advantage of the extra storage, several manufacturers developed their own FAT variants to address the problem in their MS-DOS OEM issues.

Some vendors (AST and NEC) supported eight, instead of the standard four, primary partition entries in their custom extended Master Boot Record (MBR), and they adapted MS-DOS to use more than a single primary partition.

Other vendors worked around the volume size limits imposed by the 16-bit sector entries and arithmetics by increasing the size of the sectors the file system dealt with, thereby blowing up dimensions.

These so called logical sectors were larger (up to 8192 bytes) than the physical sector size (still typically 512 bytes) as expected by the ROM-BIOS INT 13h or the disk drive hardware. The DOS-BIOS or System BIOS would then combine multiple physical sectors into logical sectors for the file system to work with. These changes were transparent to the file system implementation in the DOS kernel, since on this abstraction level volumes are a series of logically addressable sectors (starting with logical sector 0) independent of the physical location of the volume on the physical medium and its geometry. The underlying DOS-BIOS translated these logical sectors into physical sectors according to partitioning information and the drive's physical geometry.

The drawback of this approach was a less memory-efficient sector buffering and deblocking in the DOS-BIOS, thereby causing an increased memory footprint for the DOS data structures. Since older DOS versions were not flexible enough to work with these logical geometries, the OEMs had to introduce new partition IDs for their FAT variants in order to hide them from off-the-shelf issues of MS-DOS and PC DOS. Known partition IDs for logical sectored FATs include: 0x08 (Commodore MS-DOS 3.x), 0x11 (Leading Edge MS-DOS 3.x), 0x14 (AST MS-DOS 3.x), 0x24 (NEC MS-DOS 3.30), 0x56 (AT&T MS-DOS 3.x), 0xE5 (Tandy MS-DOS), 0xF2 (Sperry IT MS-DOS 3.x, Unisys MS-DOS 3.3 — also used by Digital Research DOS Plus 2.1).

While non-standard and sub-optimal, these FAT variants are perfectly valid according to the specifications of the file system itself. Therefore, even if default issues of MS-DOS and PC DOS were not able to cope with them, most of these vendor-specific FAT12 and FAT16 variants can be mounted by more flexible file system implementations in operating systems such as DR-DOS, simply by changing the partition ID to one of the recognized types. Also, if they no longer need to be recognized by their original operating systems, existing partitions can be "converted" into FAT12 and FAT16 volumes more compliant with versions of MS-DOS/PC DOS like 5.0-6.3, which don't support sector sizes different from 512 bytes, by switching to a BPB with 32-bit entry for the number of sectors, as introduced since DOS 3.31 (see FAT16B below), keeping the cluster size and reducing the logical sector size in the BPB down to 512 bytes, while at the same time increasing the counts of logical sectors per cluster, reserved logical sectors, total logical sectors, and logical sectors per FAT by the same factor.

A parallel development in MS-DOS / PC DOS which allowed an increase in the maximum possible FAT size was the introduction of multiple FAT partitions on a hard disk. To allow the use of more FAT partitions in a compatible way, a new partition type was introduced in PC DOS 3.2 (1986), the extended partition (EBR), which is a container for an additional partition called logical drive. Since PC DOS 3.3 (April 1987), there is another, optional extended partition containing the next logical drive, and so on. The 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 MS-DOS 3.31 (a modified OEM version of MS-DOS 3.3 released by Compaq with their machines) introduced what today is simply known as the FAT16 format, with the expansion of the 16-bit disk sector count to 32 bits in the BPB. Although the on-disk changes were minor, the entire DOS disk driver had to be converted to use 32-bit sector numbers, a task complicated by the fact that it was written in 16-bit assembly language. The result was initially called the DOS 3.31 Large File System. Microsoft's DSKPROBE tool refers to type 0x06 as BigFAT, whereas some older versions of FDISK described it as BIGDOS. It is also known as FAT16B.

Since older versions of DOS could not cope with more than 65535 sectors, it was also necessary to introduce a new partition type for this format, to hide it from pre-DOS 3.31 issues of DOS. While the original form of FAT16 with less than 65536 sectors had a partition type 0x04, a type 0x06 indicates 65536 or more sectors. In addition to this changed partition ID and the expansion of the disk drivers format to cope with more than 65535, the only other difference between the original FAT16 and the FAT16B format is the usage of the newer BPB with 32-bit sector entry, so that newer operating systems can cope also with the original FAT16 format without any necessary changes. If partitions to be used by pre-DOS 3.31 issues of DOS need to be created by modern tools, the only criteria theoretically necessary to meet are a sector count of less than 65536 and the usage of the old partition ID. In practice, however, type 0x01 and 0x04 partitions should not be physically located outside the first 32 MB of the disk, due to other restrictions in MS-DOS 2.x, which could not cope with them otherwise.

In 1988, the FAT16B improvement became more generally available through DR DOS 3.31, 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 originally had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB cluster size, 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, SE and ME also supported reading and writing this variant, but its disk utilities did not work with it and some FCB services are not available for such volumes. This contributes to a confusing compatibility situation.

Prior to 1995, versions of DOS accessed the disk via CHS addressing only. When MS-DOS 7.0 / Windows 95 introduced LBA disk access, partitions could start being physically located outside the first ca. 8 GB of this disk and thereby out of the reach of the traditional CHS addressing scheme. Partitions partially or fully located beyond the CHS barrier therefore had to be hidden from non-LBA-enabled operating systems by using the new partion type 0x0E in the partition table instead. FAT16 partitions using this partition type are also named FAT16X. The only difference, compared to previous FAT16 partitions, is the fact that some CHS-related geometry entries in the BPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used.

The number of root directory entries available for FAT12 and FAT16 is determined when the volume is formatted, and is stored in a 16-bit field. For a given number 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. Some third-party tools, like mkdosfs, allow the user to set this parameter.

FAT32

In order to overcome the size limit of FAT16, while at the same time allowing DOS 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. FAT32 was introduced with MS-DOS 7.1 / Windows 95 OSR2 in 1996, 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 Windows NT line, native support for FAT32 arrived in Windows 2000. A free FAT32 driver for Windows NT 4.0 was available from Winternals, a company later acquired by Microsoft. Since the acquisition the driver is no longer officially available. Since 1998, Caldera's dynamically loadable DRFAT32 driver could be used to enable FAT32 support in DR-DOS. The first version of DR-DOS to natively support FAT32 and LBA access was OEM DR-DOS 7.04 in 1999. That same year IMS introduced native FAT32 support with REAL/32 7.90, and IBM 4690 OS added FAT32 support with version 2. Ahead Software provided another dynamically loadable FAT32.EXE driver for DR-DOS 7.03 with Nero Burning ROM in 2004. IBM PC DOS introduced native FAT32 support with OEM PC DOS 7.10 in 2003.

The maximum possible size for a file on a FAT32 volume is 4 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. Video applications, large databases, and some other software easily exceed this limit.

The open FAT+ specification proposes how to store larger files up to 256 GB minus 1 byte or 274,877,906,943 (2³⁸−1) bytes on slightly modified and otherwise backwards compatible FAT32 volumes, but imposes a risk that disk tools or FAT32 implementations not aware of this extension may truncate or delete files exceeding the normal FAT32 file size limit. Also, support for FAT32+ (and FAT16+) is limited to some versions of DR-DOS and FreeDOS and not available in mainstream operating systems so far. (This extension is critically incompatible with the /EAS option of the FAT32.IFS method to store OS/2 extended attributes on FAT32 volumes.)

As with previous file systems, the design of the FAT32 file system does not include direct built-in support for long filenames, but FAT32 volumes can optionally hold VFAT long filenames in addition to short filenames in exactly the same way as VFAT long filenames have been optionally implemented for FAT12 and FAT16 volumes.

Two partition types have been reserved for FAT32 partitions, 0x0B and 0x0C. The latter type is also named FAT32X in order to indicate usage of LBA disk access instead of CHS. On such partitions, some CHS-related geometry entries in the EBPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used.

A free Windows-based FAT32 formatter is available that overcomes many of the arbitrary limitations imposed by Microsoft.

Extensions

Extended Attributes

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 two previously reserved bytes in the file's (or directory's) directory entry at offset 0x14. In the FAT32 format, these bytes hold the upper 16 bits of the starting cluster number of the file or directory, hence making it impossible to store OS/2 EAs on FAT32 using this method.

However, the third-party FAT32 installable file system (IFS) driver FAT32.IFS version 0.70 and higher by Henk Kelder & Netlabs for OS/2 and eComStation stores extended attributes in extra files with filenames having the string "␠EA.␠SF" appended to the regular filename of the file to which they belong. The driver also utilizes the byte at offset 0x0C in directory entries to store a special mark byte indicating the presence of extended attributes to help speed up things. (This extension is critically incompatible with the FAT32+ method to store files larger than 4 GB minus 1 on FAT32 volumes.)

Extended attributes are accessible via the Workplace Shell desktop, through REXX scripts, and many system GUI and command-line utilities (such as 4OS2).

To accommodate its OS/2 subsystem, Windows NT supports the handling of extended attributes in HPFS, NTFS, FAT12 and FAT16. It stores EAs on FAT12, FAT16 and HPFS using exactly the same scheme as OS/2, but does not support any other kind of ADS as held on NTFS volumes. Trying to copy a file with any ADS other than EAs from an NTFS volume to a FAT or HPFS volume gives a warning message with the names of the ADSs that will be lost. It does not support the FAT32.IFS method to store EAs on FAT32 volumes.

Windows 2000 onward acts exactly as Windows NT, except that it ignores EAs when copying to FAT32 without any warning (but shows the warning for other ADSs, like "Macintosh Finder Info" and "Macintosh Resource Fork").

Cygwin uses "EA␠DATA.␠SF" files as well.

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

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.

In order to support Java applications, the FlexOS-based IBM 4690 OS version 2 introduced their own virtual file system (VFS) architecture to store long filenames in the FAT file system in a backwards compatible fashion. If enabled, the virtual filenames (VFN) are available under separate logical drive letters, whereas the real filenames (RFN) remain available under the original drive letters.

Forks 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. Presumably, Star Trek used the same mechanisms on FAT12 and FAT16 volumes in 1992.

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

UMSDOS permissions and filenames

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.

Derivatives

FATX

FATX is a family of file systems designed for Microsoft's Xbox video game console hard disk drives and memory cards, introduced in 2001.

While resembling the same basic design ideas as FAT16 and FAT32, the FATX16 and FATX32 on-disk structures are simplified but fundamentally incompatible with normal FAT16 and FAT32 file systems, making it impossible for normal FAT file system drivers to mount such volumes.

The non-bootable superblock sector is 4 KB in size and holds a 18 byte large BPB-like structure completely different from normal BPBs. Clusters are typically 16 KB in size and there is only one copy of the FAT on the Xbox. Directory entries are 64 bytes in size instead of the normal 32 bytes. Files can have filenames up to 42 characters long using the OEM character set and be up to 4 GB minus 1 byte in size. The on-disk timestamps hold creation, modification and access dates and times but differ from FAT: in FAT, the epoch is 1980; in FATX, the epoch is 2000. On the Xbox 360, the epoch is 1980.

exFAT

exFAT is an incompatible file system, that was introduced with Windows Embedded CE 6.0 in November 2006. It is loosely based on the File Allocation Table architecture, but proprietary and protected by patents.

The MBR partition type is 0x07 (the same as used for IFS, HPFS, NTFS, etc.). exFAT is intended for use on flash drives (such as SDXC and Memory Stick XC), where FAT32 is otherwise used.

It offers several benefits over FAT32 including breaking the 4 GB file size limit of FAT32 (only without the FAT+ extension, which allows files larger than 4 GB also on FAT32 volumes), being more space-efficient for files smaller than 64 KB on large volumes and, compared to light-weight implementations of FAT32 in DOS and some embedded systems, it can offer faster seeks if more than a few thousand files are stored in a single sub-directory, whereas FAT32 is typically faster than exFAT for larger files as used on digital cameras, camcorders and media players or when flash cards are used mainly for archival purposes.

Storage devices formatted as exFAT cannot exchange data with equipment not supporting the format. Much equipment does not support exFAT, which requires acquisition of a license from Microsoft; this involves a cost, and is also against the policy of open source operating systems.

Technical design

Layout

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 Volume Boot Record (VBR)). It includes an area called the BIOS Parameter Block (with some basic file system information, in particular its type, and pointers to the location of the other sections) and usually contains the operating system's boot loader code.

Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block (DPB) in DOS and OS/2.

The total count of reserved sectors is indicated by a field inside the Boot Sector.

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 rarely used, even by disk repair utilities.

These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT12 and FAT16 they immediately follow the reserved sectors.

Typically the extra copies are kept in tight synchronization on writes, and on reads they are only used when errors occur in the first FAT. In FAT32, it is possible to switch from the default behaviour and select a single FAT out of the available ones to be used for diagnosis purposes.

• The Root Directory Region.

This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here.

• The Data Region.

This is where the actual file and directory data is stored and takes up most of the partition. Traditionally, the unused parts of the data region are initialized with a filler value of 0xF6 during format on IBM compatible machines, but also used on the Atari Portfolio. 8-inch CP/M floppies typically came pre-formatted with a value of 0xE5; by way of Digital Research this value was also used on Atari ST formatted floppies. Some modern formatters wipe hard disks with a value of 0x00, whereas a value of 0xFF is used on flash disks to reduce wear. The latter value is typically also used on ROM disks. (Some advanced formating tools allow to configure the format filler byte.)

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 all entries in the header (except for, where explicitly mentioned, for some entries on Atari ST boot sectors) and the FAT(s). It is possible to allocate more FAT sectors than necessary for the number of clusters. The end of the last 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 (VBR) 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 Boot Sector.

Common structure of the first 11 bytes used by most FAT versions for IBM compatible x86-machines since DOS 2.0 are:

FAT-formatted Atari ST floppies have a very similar boot sector layout:

FAT12-formatted MSX-DOS volumes have a very similar boot sector layout:

BIOS Parameter Block

Common structure of the first 25 bytes of the BIOS Parameter Block (BPB) used by FAT versions since DOS 2.0 are (bytes at sector offset 0x00B to 0x017 are stored since DOS 2.0, but not always used before DOS 3.2, values at 0x018 to 0x01B are used since DOS 3.0):

DOS 3.0 BPB:

DOS 3.2 BPB:

DOS 3.31 BPB:

A simple formula translates a given cluster number CN to a logical sector number LSN:

1. Determine (once) SSA=RSC+FN×SF+ceil((32×RDE)/SS), where the reserved sector count RSC is stored at offset 0x00E, the FAT number FN at offset 0x010, the sectors per FAT SF at offset 0x016 (FAT12/FAT16) or 0x024 (FAT32), the root directory entries RDE at offset 0x011, the sector size SS at offset 0x00B, and ceil(x) rounds up to a whole number.
2. Determine LSN=SSA+(CN-2)×SC, where the sectors per cluster SC are stored at offset 0x00D.

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 0x018, and the number of sides NOS at offset 0x01A. Track number TN, head number HN, and sector number SN correspond to Cylinder-head-sector: the formula gives the known CHS to LBA translation.

Extended BIOS Parameter Block

Further structure used by FAT12 and FAT16 since OS/2 1.0 and DOS 4.0, also known as Extended BIOS Parameter Block (EBPB) (bytes below sector offset 0x024 are the same as for the DOS 3.31 BPB):

FAT32 Extended BIOS Parameter Block

In essence FAT32 inserts 28 bytes into the EBPB, followed by the remaining 26 EBPB bytes as shown above for FAT12 and FAT16:

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 0x00B-0x017 in the standard sector) were located at offset 0x050. 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 for speeding up access times of certain operations (in particular, getting the amount of free space). It is located at a logical sector number specified in the FAT32 EBPB boot record at position 0x030 (usually logical sector 1, immediately after the boot record itself).

The sector's data may be outdated and not reflect the current media contents, because not all operating systems update or use this sector, and even if they do, the contents is not valid when the medium has been ejected without properly unmounting the volume or after a power-failure. Therefore, operating systems should first inspect a volume's optional shutdown status bitflags residing in the FAT entry of cluster 1 or the FAT32 EBPB at offset 0x041 and ignore the data stored in the FS information sector, if these bitflags indicate that the volume was not properly unmounted before. This does not cause any problems other than a possible speed penalty for the first free space query or data cluster allocation; see fragmentation.

If this sector is present on a FAT32 volume, the minimum allowed logical sector size is 512 bytes, whereas otherwise it would be 128 bytes. Some FAT32 implementations support a slight variation of Microsoft's specification by making the FS information sector optional by specifying a value of 0 in the entry at offset 0x030.

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 cluster-chain (EOC) entry that indicates the end of a chain
• a special entry to mark a bad cluster
• a zero to note that the cluster is unused

Each version of the FAT file system uses a different size for FAT entries. Smaller numbers result in a smaller FAT, but waste space in large partitions by needing to allocate in large clusters. The FAT12 file system uses 12 bits per FAT entry, thus two entries span 3 bytes. It is consistently little-endian: if those three bytes are considered as one little-endian 24-bit number, the 12 least significant bits represent the first entry (cluster 0) and the 12 most significant bits the second (cluster 1).

The first two entries in a FAT store special values:

The first entry (cluster 0 in the FAT) holds the media descriptor (allowed values 0xF0-0xFF with 0xF1-0xF7 reserved), which is also copied into the BPB of the boot sector, offset 0x015 since DOS 2.0. The remaining 4 bits (if FAT12), 8 bits (if FAT16) or 20 bits (if FAT32) of this entry are always 1. For media descriptors other than 0xFF (and 0x00) it is possible to determine the correct nibble and byte order (to be) used by the file system driver, however, the FAT file system officially uses a little-endian representation only and there are no known implementations of variants using big-endian values instead.

The second entry (cluster 1 in the FAT) nominally stores the end-of-cluster-chain marker as used by the formater, but typically always holds 0xFFF / 0xFFFF / 0x0FFFFFFF, that is, with the exception of bits 31-28 on FAT32 volumes these bits are normally always set. Some Microsoft operating systems, however, set these bits if the volume is not the volume holding the running operating system (that is, use 0xFFFFFFFF instead of 0x0FFFFFFF here). (In conjunction with alternative end-of-chain markers the lowest bits 2-0 can become zero for the lowest allowed end-of-chain marker 0xFF8 / 0xFFF8 / 0x?FFFFFF8; bit 3 should be reserved as well given that clusters 0xFF0 / 0xFFF0 / 0x?FFFFFF0 and higher are officially reserved.)

Since DOS 7.1 the two most-significant bits of the cluster entry may hold two optional bitflags representing the current volume status on FAT16 and FAT32, but not on FAT12 volumes. These bitflags are not supported by all operating systems, but operating systems supporting this feature would set these bits on shutdown and clear the most significant bit on startup:
If bit 15 (FAT16) respectively bit 27 (FAT32) is not set when mounting the volume, the volume was not properly unmounted before shutdown or ejection and thus is in an unknown and possibly "dirty" state. On FAT32 volumes, the FS Information Sector may hold outdated data and thus should not be used. The operating system would then typically run CHKDSK on the next startup (but not on insertion of removable media) to ensure and possibly reestablish the volume's integrity.
If bit 14 (FAT16) respectively bit 26 (FAT32) is cleared, the operating system has encountered disk I/O errors when it was last used, a possible indication for bad sectors. Operating systems aware of this extension will interpret this as a recommendation to carry out a surface scan (SCANDISK) on the next boot. (A similar set of bitflags exists in the FAT12/FAT16 EBPB at offset 0x1A or the FAT32 EBPB at offset 0x36. While the cluster 1 entry can be accessed by file system drivers once they have mounted the volume, the EBPB entry is available even when the volume is not mounted and thus easier to use by disk block device drivers or partitioning tools.)

If the number of FATs in the BPB is not set to 2, the second cluster entry in the first FAT (cluster 1) may also reflect the status of a TFAT volume for TFAT-aware operating systems. If the cluster 1 entry in that FAT holds the value 0, this may indicate that the second FAT represents the last known valid transaction state and should be copied over the first FAT, whereas the first FAT should be copied over the second FAT if all bits are set.

Because these first two FAT entries store special values, there is no data cluster 0 or 1. The first data cluster (after the root directory if FAT12/FAT16) is cluster 2.

FAT entry values:

Despite its name FAT32 uses only 28 bits of the 32 possible bits. The upper 4 bits are usually zero, but are reserved and should be left untouched. A standard conformant FAT32 file system driver or maintenance tool must not rely on the upper 4 bits to be zero and it must strip them off before evaluating the cluster number in order to cope with possible future expansions where these bits may be used for other purposes. They must not be cleared by the file system driver when allocating new clusters, but should be cleared during a reformat.

Directory table

A directory table is a special type of file that represents a directory (also known as a folder). 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 to 6.0 (up to including the 1992-11 updates) do not store absolute paths to working directories internally and therefore do not show this limitation. The same applies to Atari GEMDOS, but the Atari Desktop does not support more than 8 sub-directory levels. Most applications aware of this extension support paths up to at least 127 bytes. FlexOS, 4680 OS and 4690 OS support a length of up to 127 bytes as well, allowing depths down to 60 levels. PalmDOS, DR DOS 6.0 (since BDOS 7.1) and higher, Novell DOS, and OpenDOS sport a MS-DOS-compatible CDS and therefore have the same length limits as MS-DOS/PC DOS.

Note that before each entry there can be "fake entries" to support a long filename (LFN); see further below.

Legal characters for DOS short filenames include the following:

• Upper case letters A–Z
• Numbers 0–9
• Space (though trailing spaces in either the base name or the extension are considered to be padding and not a part of the file name, also filenames with space in them could not easily be used on the DOS command line prior to Windows 95 because of the lack of a suitable escaping system). Another exception are the internal commands MKDIR/MD 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/MS-DOS 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 following additional characters are allowed on Atari's GEMDOS, but should be avoided for compatibility with MS-DOS/PC DOS:

• " + , ; < = > [ ] |

The semicolon (;) should be avoided in filenames under DR DOS 3.31 and higher, PalmDOS, Novell DOS, OpenDOS, Concurrent DOS, Multiuser DOS, System Manager and REAL/32, because it may conflict with the syntax to specify file and directory passwords: "...\DIRSPEC.EXT;DIRPWD\FILESPEC.EXT;FILEPWD". The operating system will strip off one (and also two—since DR-DOS 7.02) semicolons and pending passwords from the filenames before storing them on disk. (The command processor 4DOS uses semicolons for include lists and requires the semicolon to be doubled for password protected files with any commands supporting wildcards.)

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.

Under IBM 4680 OS and 4690 OS, the following characters are not allowed in filenames:

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

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

• @ # ( ) { } $ &

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

Directory entry

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

Directory entries, both in the Root Directory Region and in subdirectories, are of the following format (see also 8.3 filename):

Versions of DOS prior to 5.0 start scanning directory tables from the top of the directory table to the bottom. In order to increase chances for successful file undeletion, DOS 5.0 and higher will remember the position of the last written directory entry and use this as a starting point for directory table scans.

Under DR DOS 6.0 and higher, including PalmDOS, Novell DOS and OpenDOS, the volume attribute is set for pending delete files and directories under DELWATCH.

An attribute combination of 0x0F is used to designate a VFAT long file name entry since MS-DOS 7.0. Older versions of DOS can mistake this for a directory volume label, as they take the first entry with volume attribute set as volume label. This problem can be avoided if a directory volume label is enforced as part of the format process; for this reason some disk tools explicitly write dummy "NO␠NAME␠␠␠␠" directory volume labels when the user does not specify a volume label. Since volume labels normally don't have the system attribute set at the same time, it is possible to distinguish between volume labels and VFAT LFN entries. The attribute combination 0x0F could occasionally also occur as part of a valid pending delete file under DELWATCH, however on FAT12 and FAT16 volumes, VFAT LFN entries always have the cluster value at 0x1A set to 0x0000 and the length entry at 0x1C is never 0x00000000, whereas the entry at 0x1A is always non-zero for pending delete files under DELWATCH (with the possible exception of zero-length files or deleted files following the FAT16+ proposal indicated by 0x00000000 at 0x1C). This check does not work on FAT32 volumes.

• CP/M-86 and DOS Plus store user attributes F1'—F4' here. (DOS Plus 1.2 with BDOS 4.1 supports passwords only on CP/M media, not on FAT12 or FAT16 media. While DOS Plus 2.1 supported logical sectored FATs with a partition type 0xF2, FAT16B and FAT32 volumes were not supported by these operation systems. Even if a partition would have been converted to FAT16B it would still not be larger than 32 MB. Therefore, this usage is not conflictive with FAT32.IFS, FAT16+ or FAT32+ as they can never occur on the same type of volume.):

• MSX-DOS 2: For a deleted file, the original first character of the filename. For the same feature in various other operating systems, see offset 0x0D if enabled in MSX boot sectors at sector offset 0x026. MSX-DOS supported FAT12 volumes only, but third-party extensions for FAT16 volumes exist. Therefore, this usage is not conflictive with FAT32.IFS and FAT32+ below. It does not conflict with the usage for user attributes under CP/M-86 and DOS Plus as well, since they are no longer important for deleted files.

• Windows NT and later versions uses bits 3 and 4 to encode case information (see below); otherwise 0.

• DR-DOS 7.0x reserved bits other than 3 and 4 for internal purposes since 1997. The value should be set to 0 by formating tools and must not be changed by disk tools.

• On FAT32 volumes under OS/2 and eComStation the third-party FAT32.IFS driver utilizes this entry as a mark byte to indicate the presence of extra "␠EA.␠SF" files holding extended attributes with parameter /EAS. Version 0.70 to 0.96 used the magic values 0x00 (no EAs), 0xEA (normal EAs) and 0xEC (critical EAs), whereas version 0.97 and higher since 2003-09 use 0x00, 0x40 (normal EAs) and 0x80 (critical EAs) as bitflags for compatibility with Windows NT.

• Bits other than 3 and 4 are utilized by FAT+, a proposal how to store files larger than 4 GB on FAT32 (and FAT16B) volumes, currently implemented in some versions of EDR-DOS and FreeDOS. The value should be set to 0 by formating tools and must not be changed by disk tools. If some of these bits are set, non-enabled implementations should refuse to open the file. To avoid problems with non-aware operating systems, partitions containing files larger than 4 GB could use non-standard partition IDs to hide the partition from these operating systems. Under DR-DOS, partition IDs of secured partition types can be utilized for this purpose. Files larger than 4 GB should have the Hidden, Read-only and System attributes set to hide them from normal directory searches on non-aware operating systems, similar to password protected files under DR-DOS. While FAT+ implementations do not rely on these attributes being set, for FAT+ large files they may ignore these attributes in file searches and when opening large files for modification and instead treat the System attribute as an alternative combined Read-only+Hidden attribute in this scenario.

FAT32.IFS is critically conflictive with FAT32+ revision 2.

• 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. S/DOS 1 and PTS-DOS 6.51 and higher also support this feature if enabled with SAVENAME=ON in CONFIG.SYS. For the same feature in MSX-DOS, see offset 0x0C.

• Create time, Fine resolution: 10 ms units, values from 0 to 199 (since DOS 7.0 with VFAT).

Double usage for create time ms and file char is not conflictive, since the creation time is no longer important for deleted files.

• Under DR DOS 3.31 and higher including PalmDOS, Novell DOS and OpenDOS as well as under Concurrent DOS, Multiuser DOS, System Manager, and REAL/32 and possibly also under FlexOS, 4680 OS, 4690 OS any non-zero value indicates the password hash of a protected file, directory or volume label. The hash is calculated from the first eight characters of a password. If the file operation to be carried out requires a password as per the access rights bitmap stored at offset 0x14, the system tries to match the hash against the hash code of the currently set global password (by PASSWORD /G) or, if this fails, tries to extract a semicolon-appended password from the filespec passed to the operating system and checks it against the hash code stored here. A set password will be preserved even if a file is deleted and later undeleted.

• Create time (since DOS 7.0 with VFAT). The hour, minute and second are encoded according to the following bitmap:

The seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0D.

If bits 15-11 > 23 or bits 10-5 > 59 or bits 4-0 > 29 here, or when bits 12-0 at offset 0x14 hold an access bitmap and this is not a FAT32 volume or a volume using OS/2 Extended Attributes, then this entry actually holds a password hash, otherwise it can be assumed to be a file creation time.

• FlexOS, 4680 OS and 4690 OS store a record size in the word at entry 0x10. This is mainly used for their special database-like file types random file, direct file, keyed file, and sequential file. If the record size is set to 0 (default) or 1, the operating systems assume a record granularity of 1 byte for the file, for which it will not perform record boundary checks in read/write operations.

• With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified time stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x0E for a format description.

• Create date (since DOS 7.0 with VFAT). The year, month and day are encoded according to the following bitmap:

The usage for creation date for existing files and last modified time for deleted files is not conflictive because they are never used at the same time. For the same reason, the usage for the record size of existing files and last modified time of deleted files is not conflictive as well. Creation dates and record sizes cannot be used at the same time, however, both are stored only on file creation and never changed later on, thereby limiting the conflict to FlexOS, 4680 OS and 4690 OS systems accessing files created under foreign operating systems as well as potential display or file sorting problems on systems trying to interpret a record size as creation time. To avoid the conflict, the storage of creation dates should be an optional feature of operating systems supporting it.

• FlexOS, 4680 OS, 4690 OS, Multiuser DOS, System Manager, REAL/32 and DR DOS 6.0 and higher with multi-user security enabled use this field to store owner IDs. Offset 0x12 holds the user ID, 0x13 the group ID of a file's creator.

In multi-user versions, system access requires a logon with account name and password, and the system assigns group and user IDs to running applications according to the previously set up and stored authorization info and inheritance rules. For 4680 OS and 4690 OS, group ID 1 is reserved for the system, group ID 2 for vendor, group ID 3 for the default user group. Background applications started by users have a group ID 2 and user ID 1, whereas operating system background tasks have group IDs 1 or 0 and user IDs 1 or 0. IBM 4680 BASIC and applications started as primary or secondary always get group ID 2 and user ID 1. When applications create files, the system will store their user ID and group ID and the required permissions with the file.

• With DELWATCH 2.00 and higher under Novell DOS 7, OpenDOS 7.01 and DR-DOS 7.02 and higher, this entry is used to store the last modified date stamp for pending delete files and directories. Cleared when file is undeleted or purged. See offset 0x10 for a format description.

• Last access date (since DOS 7.0 if ACCDATE enabled in CONFIG.SYS for the corresponding drive); see offset 0x10 for a format description.

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.

• Access rights bitmap for world/group/owner read/write/execute/delete protection for password protected files, directories (or volume labels) under DR DOS 3.31 and higher, including PalmDOS, Novell DOS and OpenDOS, and under FlexOS, 4680 OS, 4690 OS, Concurrent DOS, Multiuser DOS, System Manager, and REAL/32.

Typical values stored on a single-user system are 0x0000 (PASSWORD /N for all access rights "RWED"), 0x0111 (PASSWORD /D for access rights "RW?-"), 0x0555 (PASSWORD /W for access rights "R-?-") and 0x0DDD (PASSWORD /R for files or PASSWORD /P for directories for access rights "--?-"). Bits 1, 5, 9, 12-15 will be preserved when changing access rights. If execute bits are set on systems other than FlexOS, 4680 OS or 4690 OS, they will be treated similar to read bits. (Some versions of PASSWORD allow to set passwords on volume labels (PASSWORD /V) as well.)

Single-user systems calculate the most restrictive rights of the three sets (DR DOS up to 5.0 used bits 0-3 only) and check if any of the requested file access types requires a permission and if a file password is stored. If not, file access is granted. Otherwise the stored password is checked against an optional global password provided by the operating system and an optional file password provided as part of the filename separated by a semicolon (not under FlexOS, 4680 OS, 4690 OS). If neither of them is provided, the request will fail. If one of them matches, the system will grant access (within the limits of the normal file attributes, that is, a read-only file can still not be opened for write this way), otherwise fail the request.

Under FlexOS, 4680 OS and 4690 OS the system assigns group and user IDs to applications when launched. When they request file access, their group and user IDs are compared with the group and user IDs of the file to be opened. If both IDs match, the application will be treated as file owner. If only the group ID matches, the operating system will grant group access to the application, and if the group ID does not match as well, it will grant world access. If an application's group ID and user ID are both 0, the operating system will bypass security checking. Once the permission class has been determined, the operating system will check if any of the access types of the requested file operation requires a permission according to the stored bitflags of the selected class owner, group or world in the file's directory entry. Owner, group and world access rights are independant and do not need to have diminishing access levels. Only, if none of the requested access types require a permission, the operating system will grant access, otherwise it fails.

If multiuser file / directory password security is enabled the system will not fail at this stage but perform the password checking mechanism for the selected permission class similar to the procedure described above. With multi-user security loaded many utilities since DR DOS 6.0 will provide an additional /U:name parameter.

File access rights bitmap:

File renames require either write or delete rights, IBM 4680 BASIC CHAIN requires execute rights.

• Extended Attributes handle (used by OS/2 1.2 and higher as well as by Windows NT) in FAT12 and FAT16; first cluster of EA file or 0, if not used. A different method to store extended attributes has been devised for FAT32 volumes, see FAT32.IFS under offset 0x0C.

• High two bytes of first cluster number in FAT32; with the low two bytes stored at offset 0x1A.

The storage of the high two bytes of the first cluster in a file on FAT32 is partially conflictive with access rights bitmaps.

• Last modified time (since DOS 1.1); see offset 0x0E for a format description.

• Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion time of pending delete files or directories under DELWATCH 2.00 or higher. The last modified time stamp is copied to 0x10 for possible later restoration. See offset 0x0E for a format description.

• Last modified date; see offset 0x10 for a format description.

• Under Novell DOS, OpenDOS and DR-DOS 7.02 and higher, this entry holds the deletion date of pending delete files or directories under DELWATCH 2.00 or higher. The last modified date stamp is copied to 0x12 for possible later restoration. See offset 0x10 for a format description.

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

VFAT LFN entries also have this entry set to 0; on FAT12 and FAT16 volumes this can be used as part of a detection mechanism to distinguish between pending delete files under DELWATCH and VFAT LFNs; see above.

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

For files larger than 4 GB following the FAT+ proposal, this entry only holds the size of the last chunk of the file (that is bits 31-0). The most significant bits 37-32 are stored in the entry at offset 0x0C.

The FlexOS-based operating systems IBM 4680 OS and IBM 4690 OS support unique distribution attributes stored in some bits of the previously reserved areas in the directory entries:

1. Local: Don't distributed file but keep on local controller only.
2. Mirror file on update: Distribute file to server only when file is updated.
3. Mirror file on close: Distribute file to server only when file is closed.
4. Compound file on update: Distribute file to all controllers when file is updated.
5. Compound file on close: Distribute file to all controllers when file is closed.

Some incompatible extensions found in some operating systems include:

VFAT long file names

VFAT Long File Names (LFN) are stored on a FAT file system using a trick—adding (possibly multiple) additional entries into the directory before the normal file entry. The additional entries are marked with the Volume Label, System, Hidden, and Read Only attributes (yielding 0x0F), which is a combination that is not expected in the MS-DOS environment, and therefore ignored by MS-DOS programs and third-party utilities. Notably, a directory containing only volume labels is considered as empty and is allowed to be deleted; such a situation appears if files created with long names are deleted from plain DOS. This method is very similar to the DELWATCH method to utilize the volume attribute to hide pending delete files for possible future undeletion since DR DOS 6.0 (1991) and higher.

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.

After the last UTF-16 character, a 0x0000 is added. The remaining unused characters are filled with 0xFFFF.

LFN entries use the following format:

If there are multiple LFN entries, required to represent a file name, firstly comes the last LFN entry (the last part of the filename). The sequence number also has bit 6 (0x40) set (this means the last LFN entry, however it's the first entry seen when reading the directory file). The last LFN entry has the largest sequence number which decreases in following entries. The first LFN entry has sequence number 1. A value of 0xE5 is used to indicate that the entry is deleted.

On FAT12 and FAT16 volumes, testing for the values at 0x1A to be zero and at 0x1C to be non-zero can be used to distinguish between VFAT LFNs and pending delete files under DELWATCH.

For example if we have filename "File with very long filename.ext" it would be formatted like this:

A checksum also allows verification of whether a long file name matches the 8.3 name; such a mismatch could occur if a file was deleted and re-created using DOS in the same directory position. The checksum is calculated using the algorithm below. (Note that pFCBName is a pointer to the name as it appears in a regular directory entry, i.e. the first eight characters are the filename, and the last three are the extension. The dot is implicit. Any unused space in the filename is padded with space characters (ASCII 0x20). For example, "Readme.txt" would be "README␠␠TXT".)

unsigned char lfn_checksum(const unsigned char *pFCBName)
{
   int i;
   unsigned char sum = 0;
 
   for (i = 11; i; i--)
      sum = ((sum & 1) << 7) + (sum >> 1) + *pFCBName++;
 
   return sum;
}

If a filename contains only lowercase letters, or is a combination of a lowercase basename with an uppercase extension, or vice-versa; and has no special characters, and fits within the 8.3 limits, a VFAT entry is not created on Windows NT and later versions of Windows such as XP. Instead, two bits in byte 0x0C of the directory entry are used to indicate that the filename should be considered as entirely or partially lowercase. Specifically, bit 4 means lowercase extension and bit 3 lowercase basename, which allows for combinations such as "example.TXT" or "HELLO.txt" but not "Mixed.txt". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (Windows 95 / 98 / 98 SE / ME) that see all-uppercase filenames if this extension has been used, and therefore can change the name of a file when it is transported between operating systems, such as on a USB flash drive. Current 2.6.x versions of Linux will recognize this extension when reading (source: kernel 2.6.18 /fs/fat/dir.c and fs/vfat/namei.c); the mount option shortname determines whether this feature is used when writing.

Size limits

The FAT12, FAT16, FAT16B, and FAT32 variants of the FAT file systems have clear limits based on the number of clusters and the number of sectors per cluster (1, 2, 4, ..., 128). For the typical value of 512 bytes per sector:

FAT12 requirements : 3 sectors on each copy of FAT for every 1,024 clusters
FAT16 requirements : 1 sector on each copy of FAT for every 256 clusters
FAT32 requirements : 1 sector on each copy of FAT for every 128 clusters

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

FAT12 minimum : 1 sector per cluster × 1 clusters = 512 bytes (0.5 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 0x0FFFFFF7, because FAT32 version 0 uses only 28 bits in the 32-bit cluster numbers, cluster numbers 0x0FFFFFF7 up to 0x0FFFFFFF flag bad clusters or the end of a file, cluster number 0 flags a free cluster, and cluster number 1 is not used. Likewise 65524+3 is 0xFFF7 for FAT16, and 4084+3 is 0xFF7 for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 (0x01), the biggest value is 128 (0x80). Lines in square brackets indicate the unusual cluster size 128, and for FAT32 the bigger than necessary cluster sizes 32 or 64.

Because each FAT32 entry occupies 32 bits (4 bytes) the maximal number of clusters (268435444) requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is 0x200000, and storing this value needs more than two bytes. Therefore FAT32 introduced a new 32-bit value in the FAT32 boot sector immediately following the 32-bit value for the total number of sectors introduced in the FAT16B variant.

The boot record extensions introduced with DOS 4.0 start with a magic 40 (0x28) or 41 (0x29). Typically FAT drivers look only at the number of clusters to distinguish FAT12, FAT16, and FAT32: the human readable strings identifying the FAT variant in the boot record are ignored, because they exist only for media formatted with DOS 4.0 or later.

Determining the number of directory entries per cluster is straight forward, each entry occupies 32 bytes, this results in 16 entries per sector for a sector size of 512 bytes. The DOS 5 RMDIR/RD command removes the initial "." (this directory) and ".." (parent directory) entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12, but requires 2 or more sectors per cluster. A FAT12 boot sector without the DOS 4 extensions needs 29 bytes before the first unnecessary FAT16B 32-bit number of hidden sectors, this leaves three bytes for the (on a RAM disk unused) boot code and the magic 0x55 0xAA at the end of all boot sectors. On Windows NT the smallest supported sector size is 128.

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

Both editions of each ECMA-107 and ISO/IEC 9293 specify a Max Cluster Number MAX determined by the formula MAX=1+trunc((TS-SSA)/SC), and reserve cluster numbers MAX+1 up to 4086 (0xFF6, FAT12) and later 65526 (0xFFF6, FAT16) for future standardization.

Microsoft's EFI FAT32 specification states that any FAT file system with less than 4085 clusters is FAT12, else any FAT file system with less than 65525 clusters is FAT16, and otherwise it is FAT32. The entry for cluster 0 at the beginning of the FAT must be identical to the media descriptor byte found in the BPB, whereas the entry for cluster 1 reflects the end-of-chain value used by the formatter for cluster chains (0xFFF, 0xFFFF or 0x0FFFFFFF). The entries for cluster numbers 0 and 1 end at a byte boundary even for FAT12, e.g., 0xF9FFFF for media descriptor 0xF9.

The first data cluster is 2, and consequently the last cluster MAX gets number MAX+1. This results in data cluster numbers 2...4085 (0xFF5) for FAT12, 2...65525 (0xFFF5) for FAT16, and 2...268435445 (0x0FFFFFF5) for FAT32.

The only available values reserved for future standardization are therefore 0xFF6 (FAT12) and 0xFFF6 (FAT16). As noted below "less than 4085" is also used for Linux implemementations, or as Microsoft's FAT specification puts it:

when it says <, it does not mean <=. Note also that the numbers are correct. The first number for FAT12 is 4085; the second number for FAT16 is 65525. These numbers and the ‘<’ signs are not wrong.

Fragmentation

The FAT file system does not contain built-in mechanisms which prevent newly written files from becoming scattered across the partition. On volumes where files are created and deleted frequently or their lengths often changed, the medium will become increasingly fragmented over time.

While the design of the FAT file system does not cause any organizational overhead in disk structures or reduce the amount of free storage space with increased amounts of fragmentation, as it occurs with external fragmentation, the time required to read and write fragmented files will increase as the operating system will have to follow the cluster chains in the FAT (with parts having to be loaded into memory first in particular on large volumes) and read the corresponding data physically scattered over the whole medium reducing chances for the low-level block device driver to perform multi-sector disk I/O or initiate larger DMA transfers, thereby effectively increasing I/O protocol overhead as well as arm movement and head settle times inside the disk drive. Also, file operations will become slower with growing fragmentation as it takes increasingly longer for the operating system to find files or free clusters.

Other file systems, e.g. HPFS or exFAT, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in Unix file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.

In fact, seeking for files in large subdirectories or computing the free disk space on FAT volumes is one of the most resource intensive operations, as it requires reading the directory tables or even the entire FAT linearly. Since the total amount of clusters and the size of their entries in the FAT was still small on FAT12 and FAT16 volumes, this could still be tolerated on FAT12 and FAT16 volumes most of the time, considering that the introduction of more sophisticated disk structures would have also increased the complexity and memory footprint of real-mode operating systems with their minimum total memory requirements of 128 KB or less (such as with DOS) for which FAT has been designed and optimized originally.

With the introduction of FAT32, long seek and scan times became more apparent, particularly on very large volumes. A possible justification suggested by Microsoft's Raymond Chen for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "DIR" operation, which always displays the free disk space as the last line. Displaying this line took longer and longer as the number of clusters increased. FAT32 therefore introduced a special file system information sector where the previously computed amount of free space is preserved over power cycles, so that the free space counter needs to be recalculated only when a removable FAT32 formatted medium gets ejected without first unmounting it or if the system is switched off without properly shutting down the operating system, a problem mostly visible with pre-ATX-style PCs, on plain DOS systems and some battery-powered consumer products.

With the huge cluster sizes (16 KB, 32 KB, 64 KB) forced by larger FAT partitions, internal fragmentation in form of disk space waste by file slack due to cluster overhang (as files are rarely exact multiples of cluster size) starts to be a problem as well, especially when there are a great many small files.

Various optimizations and tweaks to the implementation of FAT file system drivers, block device drivers and disk tools have been devised to overcome most of the performance bottlenecks in the file system's inherit design without having to change the layout of the on-disk structures. They can be divided into on-line and off-line methods and work by trying to avoid fragmentation in the file system in the first place, deploying methods to better cope with existing fragmentation, and by reordering and optimizing the on-disk structures. With optimizations in place, the performance on FAT volumes can often reach that of more sophisticated file systems in practical scenarios, while at the same time retaining the advantage of being accessible even on very small or old systems.

DOS 3.0 and higher will not immediately reuse disk space of deleted files for new allocations but instead seek for previously unused space before starting to use disk space of previously deleted files as well. This not only helps to maintain the integrity of deleted files for as long as possible but also speeds up file allocations and avoids fragmentation, since never before allocated disk space is always unfragmented. DOS accomplishes this by keeping a pointer to the last allocated cluster on each mounted volume in memory and start searching for free space from this location upwards instead of at the beginning of the FAT, as it was still done by DOS 2.x. If the end of the FAT is reached, it would wrap around to continue the search at the beginning of the FAT until either free space has been found or the original position has been reached again without having found free space. These pointers are initialized to point to the start of the FATs after bootup, but on FAT32 volumes, DOS 7.1 and higher will attempt to retrieve the last position from the FS Information Sector. This mechanism is defeated, however, if an application often deletes and recreates temporary files as the operating system would then try to maintain the integrity of void data effectively causing more fragmentation in the end. In some DOS versions, the usage of a special API function to create temporary files can be used to avoid this problem.

Additionally, directory entries of deleted files will be marked 0xE5 since DOS 3.0. DOS 5.0 and higher will start to reuse these entries only when previously unused directory entries have been used up in the table and the system would otherwise have to expand the table itself.

Since DOS 3.3 the operating system provides means to improve the performance of file operations with FASTOPEN by keeping track of the position of recently opened files or directories in various forms of lists (MS-DOS/PC DOS) or hash tables (DR-DOS), which can reduce file seek and open times significantly. Before DOS 5.0 special care must be taken when using such mechanisms in conjunction with disk defragmentation software bypassing the file system or disk drivers.

Windows NT will allocate disk space to files on FAT in advance, selecting large contiguous areas, but in case of a failure, files which were being appended will appear larger than they were ever written into, with a lot of random data at the end.

Other high-level mechanisms may read in and process larger parts or the complete FAT on startup or on demand when needed and dynamically build up in-memory tree representations of the volume's file structures different from the on-disk structures. This may, on volumes with many free clusters, occupy even less memory than an image of the FAT itself. In particular on highly fragmented or filled volumes, seeks become much faster than with linear scans over the actual FAT, even if an image of the FAT would be stored in memory. Also, operating on the logically high level of files and cluster-chains instead of on sector or track level, it becomes possible to avoid some degree of file fragmentation in the first place or to carry out local file defragmentation and reordering of directory entries based on their names or access patterns in the background.

Some of the perceived problems with fragmentation of FAT file systems also result from performance limitations of the underlying block device drivers, which 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 strategies or even run in protected mode through DPMS or Cloaking to increase performance by gaining direct access to the cached data in linear memory rather than through conventional DOS APIs.

Write-behind caching was often not enabled by default with Microsoft software (if present) given the problem of data loss in case of a power failure or crash, made easier by the lack of hardware protection between applications and the system.

Legal issues

Licensing

This section may contain original research. Please improve it by verifying the claims made and adding references. Statements consisting only of original research may be removed. More details may be available on the talk page. (December 2011)

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 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. 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").
• 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 on 2004-09-14, due to prior disclosure 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". 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.

In the EFI FAT32 specification 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. As a USA patent filed before 1995, it would have expired after the later of the filing date plus 20 years, or the issue date plus 17 years. The patent was issued on 1994-11-24, so it expired in 2011.

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

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 file system. As some TomTom products are based on Linux, this marked the first time that Microsoft tried to enforce its patents against the Linux platform. 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 file system from its products, and that in return Microsoft not seek legal action against TomTom for the five year duration of the settlement agreement.

In October 2010, Microsoft filed a patent infringement lawsuit against Motorola alleging several patents (including two of the FAT32 file system patents) were not licensed for use in the Android operating system. They also submitted a complaint to the ITC. Developers of open source software have designed methods intended to circumvent Microsoft's patents.

See also

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

Notes

1. ^ ^{a b c d e} See other links for special precautions in regard to occurances of a cluster value of 0xFF0 on FAT12 volumes under MS-DOS/PC DOS 3.3 and higher.
2. ^ 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.
3. ^ ^{a b} This is the reason, why 0xE5 had a special meaning in directory entries.
4. ^ One utility providing an option to specify the desired format filler value for hard disks is DR-DOS' FDISK R2.31 with its optional wipe parameter /W:246. In contrast to other FDISK utilities, DR-DOS FDISK is not only a partitioning tool, but can also format freshly created partitions as FAT12, FAT16 or FAT32. This reduces the risk to accidentally format wrong volumes.
5. ^ ^{a b} For maximum compatibility with MS-DOS/PC DOS and DR-DOS, operating systems trying to determine a floppy disk's format should test on all mentioned opcode sequences at sector offset 0x000 in addition to looking for a valid media descriptor byte at sector offset 0x015 before assuming the presence of a BPB. Although PC DOS 1.0 floppy disks do not contain a BPB, they start with 0xEB as well, but do not show a 0x90 at offset 0x002. PC DOS 1.10 floppy disks even start with 0xEB 0x?? 0x90, although they still do not feature a BPB. In both cases, a test for a valid media descriptor at offset 0x015 would fail (value 0x00 instead of valid media descriptors 0xF0 and higher). If these tests fail, DOS checks for the presence of a media descriptor byte in the first byte of the first FAT in the sector following the boot sector (logical sector 1 on FAT12/FAT16 floppies).
6. ^ ^{a b c d e} The signature at offset 0x1FE in boot sectors is 0x55 0xAA, that is 0x55 at offset 0x1FE and 0xAA at offset 0x1FF. Since little-endian representation must be assumed in the context of IBM PC compatible machines, this can be written as 16-bit word 0xAA55 in programs for x86 processors (note the swapped order), whereas it would have to be written as 0x55AA in programs for other CPU architectures using a big-endian representation. Since this has been mixed up numerous times in books and even in original Microsoft reference documents, this article uses the offset-based byte-wise on-disk representation to avoid any possible misinterpretation.
7. ^ ^{a b c} The checksum entry in Atari boot sectors holds the alignment value, not the magic value itself. The magic value 0x1234 is not stored anywhere on disk. In contrast to Intel x86 processors, the Motorola 680x0 processors as used in Atari machines use a big-endian memory representation and therefore a big-endian representation must be assumed when calculating the checksum. As a consequence of this, for checksum verification code running on x86 machines, pairs of bytes must be swapped before the 16-bit addition.
8. ^ To avoid potential misinterpretation of directory volume labels with VFAT LFN entries by non-VFAT aware operating systems, the DR-DOS 7.07 FDISK and FORMAT tools are known to explicitly write dummy "NO␠NAME␠␠␠␠" directory volume labels if the user skips entering a volume label. The operating system would internally default to return the same string if no directory volume label could be found in the root of a volume, but without a real volume label stored as the first entry (after the directory entries), older operating systems could erroneously pick up VFAT LFN entries instead.
9. ^ This IBM 4680 OS and 4690 OS distribution attribute type must have an on-disk bit value of 0 as files fall back to this type when attributes get lost accidentally.

References

External links

• ECMA-107 Volume and File Structure of Disk Cartridges for Information Interchange, identical to ISO/IEC 9293.
• Microsoft Extensible Firmware Initiative FAT32 File System Specification, FAT: General Overview of On-Disk Format
• Understanding FAT32 file systems (explained for embedded firmware developers)
• Understanding FAT including lots of info about LFNs
• Detailed Explanation of FAT Boot Sector: Microsoft Knowledge Base Article 140418
• Description of the FAT32 File System: Microsoft Knowledge Base Article 154997
• FAT12/FAT16/FAT32 file system implementation for *nix: Includes libfat libraries and fusefat, a FUSE file system driver
• MS-DOS: Directory and Subdirectory Limitations: Microsoft Knowledge Base Article 39927
• Overview of FAT, HPFS, and NTFS File Systems: Microsoft Knowledge Base Article 100108
• Volume and file size limits of FAT file systems: Microsoft Technet
• Microsoft TechNet: A Brief and Incomplete History of FAT32 by Raymond Chen
• FAT32 Formatter: allows formatting volumes larger than 32 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
• FAT File System