User:Valency/My draft

File Allocation Table (FAT) is a widely used computer file system architecture. Initially designed as a format for floppy disks used with the MS-DOS operating system, variants of FAT are now found on computer hard drives, USB drives, flash memory cards, and a variety other storage media. FAT was the standard hard disk file system 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. It remains a popular format on memory cards and thumb drives because it is simple to implement, and because it is understood by virtually all operating systems and other devices which use a file system for storage.

The FAT file system derives its name from its central structure, the File Allocation table, which uses linked allocation to keep track of the storage space allocated to each file.

FAT has evolved over time and a number of variants exist. The three major variants are FAT-12, FAT-16, and FAT-32. With FAT, the files are allocated in chunks called "clusters." The number (12, 16 or 32) represents the number of bits used to store the unique number that indexes each cluster. Thus there is a hard limit of 2^12=4096 clusters using FAT-12, 2^16=60536 entries using FAT-16, and 2^32=4294967296 entries using FAT-32. The actual number of clusters supportable on a storage device is slightly lower because some index numbers are reserved for special purposes.

Aside from the cluster limits, the FAT 12 and FAT-16 formats have a number of other hard limits. The commonly encountered by users is the limit on the length of file names: just eight characters for the file name, plus a three character "extension." This limitation can make giving files human readable, descriptive names extremely difficult. For example, instead of naming a file "4th_quarter_human_resource_dept_report_1988.doc", the 8_3 limit meant it would have to be abbreviated: say, '4rephr88.doc'. Other, less known limits include the fixed number of root directory entries: 224 on a standardly formatted disk.

FAT-32 was a significant upgrade which fixed the 8+3 character file name limit by allowing file names of up to 254 characters. Because FAT-32 needed to preserve backwards compatibility with older software, every file on a FAT-32 formatted device has two file names associated with it, the "short" file anme and the long, or extended fil name.

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

History
Designed and coded by Marc McDonald, Microsoft Stand-alone Disk BASIC introduced the FAT in 1977 with 8-bit table elements, produced for NCR's 8-bit 8080 file system. The FAT, born during one of a series of discussions between McDonald and Bill Gates, was later used in a stand-alone BASIC for the 8086 chip and eventually through the M-DOS operating system, became the basis for the file-handling routines in MS-DOS. In 1980, Tim Paterson extended the table elements to 12 bits in 86-DOS, which supported 8-inch floppy drives.

IBM PC-DOS 1.0, released with the original IBM Personal Computer in 1981, supported single-sided 5.25-inch floppy drives, and PC-DOS 1.1 added double-sided support. Neither of these versions had a BIOS parameter block. The BPB was introduced in PC-DOS 2.0. PC-DOS 1.0 directory entries included only one date, the last modified date. PC-DOS 1.1 added the last modified time. PC-DOS 1.x file attributes included a hidden bit and system bit, with the remaining six bits undefined. PC-DOS 2.0 added read-only, volume label, subdirectory and archive attribute bits.

FAT12
The initial version of FAT designed for 16-bit microprocessors is now referred to as FAT12. Designed as a file system for floppy disks, it limited cluster addresses to 12-bit values, which not only limited the cluster count to 4084, but made FAT manipulation tricky with the PC's 8-bit and 16-bit registers. (The literature also mentions a limit 4078. ) The disk's size is stored as a 16-bit count of sectors, which limited the size to 32 MB. FAT12 was used by several manufacturers with different physical formats, but a typical floppy disk at the time was 5.25-inch, single-sided, 40 tracks, with 8 sectors per track, resulting in a capacity of 160 KB for both the system areas and files. The FAT12 limitations exceeded this capacity by a factor of ten or more.

FAT always includes two, redundant copies of the File Allocation Table, as a guard against media errors. However, there are still a number of single points of failure, such a the suuperblock.

By convention, all the control structures were organized to fit inside the first track, thus avoiding head movement during read and write operations, although this varied depending on the manufacturer and physical format of the disk. At the time FAT12 was introduced, DOS did not support hierarchical directories, and the maximum number of files was typically limited to a few dozen. Hierarchical directories were introduced in MS-DOS version 2.0.

A limitation which was not addressed until much later was that any bad sector in the control structures area, track 0, could prevent the disk from being usable. The DOS formatting tool rejected such disks completely. Bad sectors were allowed only in the file area, where they made the entire containing cluster unusable. FAT12 remains in use on all common floppy disks, including 1.44 MB disks.

Initial FAT16
In 1984, IBM released the PC AT, which featured a 20 MB hard disk. Microsoft introduced MS-DOS 3.0 in parallel. Cluster addresses were increased to 16-bit, allowing for up to 65,524 clusters per volume, and consequently much greater file system sizes, at least in theory. However, the maximum possible number of sectors and the maximum (partition, rather than disk) size of 32 MB did not change. Therefore, although cluster addresses were 16 bits, this format was not what today is commonly understood as FAT16. With the initial implementation of FAT16 not actually providing for larger partition sizes than FAT12, the early benefit of FAT16 was to enable the use of smaller clusters, making disk usage more efficient, particularly for files several hundred bytes in size, which were far more common at the time.

MS-DOS 2.x hard disks larger than 15 MB are incompatible with later versions of MS-DOS. A 20 MB hard disk formatted under MS-DOS 3.0 was not accessible by the older MS-DOS 2.0 because MS-DOS 2.0 did not support version 3.0's FAT16. MS-DOS 3.0 could still access MS-DOS 2.0 style 8 kB-cluster partitions under 15 MB. MS-DOS 3.0 also introduced support for high-density 1.2 MB 5.25" diskettes, which notably had 15 sectors per track, hence more space for the FATs.

Partitioning and logical drives
Apart from improving the structure of the FAT file system itself, a parallel development allowing an increase in the maximum possible FAT size was the introduction of multiple FAT partitions on a hard disk. To allow the use of more FAT partitions in a compatible way, a new partition type was introduced (in MS-DOS 3.2, January 1986), the extended partition, which is a container for an additional partition called logical drive and optionally another extended partition containing the next logical drive, and so on. The MBR of a hard disk can either define up to four primary partitions, or an extended partition in addition to up to three primary partitions.

Final FAT16
Finally in November 1987, Compaq DOS 3.31 (an OEM version of MS-DOS 3.3 released by Compaq with their machines) introduced what today is simply known as the FAT16 format, with the expansion of the 16-bit disk sector count to 32 bits. The result was initially called the DOS 3.31 Large File System. Although the on-disk changes were minor, the entire DOS disk driver had to be converted to use 32-bit sector numbers, a task complicated by the fact that it was written in 16-bit assembly language. FAT16 partition type hex. 04 indicates less than 65536 sectors (less than 32 MB for sector size 512), type 06 indicates 65536 or more sectors, and hex. 0E indicates LBA instead of CHS addressing. Microsoft's dskprobe tool refers to type 06 as BigFAT, whereas some older versions of FDISK described it as BIGDOS. It is also known as FAT16B.

In 1988 this improvement became more generally available through DR DOS 3.31, MS-DOS 4.0 and OS/2 1.1. The limit on partition size was dictated by the 8-bit signed count of sectors per cluster, which had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 partition size at 2 GB for sector size 512. On magneto-optical media, which can have 1 or 2 KB sectors instead of 0.5 KB, this size limit is proportionally larger.

Much later, Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk utilities did not work with it. This contributes to a confusing compatibility situation.

The number of root directory entries available for FAT12 and FAT16 is determined when the volume is formatted, and is stored in a 16-bit field. For a given number RDE</tt> and sector size <tt>SS</tt> the number <tt>RDS</tt> of root directory sectors is <tt>RDS=ceil((RDE&times;32)/SS)</tt>, and <tt>RDE</tt> is normally chosen to fill these sectors, i.e., <tt>RDE*32=RDS*SS</tt>. 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.

Long file names
One of the user experience goals for the designers of Windows 95 was the ability to use long filenames (LFNs—up to 255 UTF-16 code points long), in addition to classic 8.3 filenames. LFNs were implemented using a workaround in the way directory entries are laid out (see below).

The version of the file system with this extension is usually known as VFAT after the Windows 95 virtual device driver, also known as "Virtual FAT" in Microsoft's documentation. The VFAT driver appeared before Windows 95, in Windows for Workgroups 3.11, but was only used for implementing 32-bit file access and did not support long file names.

In Windows NT, support for long filenames on FAT started from version 3.5. OS/2 added long filename support to FAT using extended attributes (EA) before the introduction of VFAT; thus, VFAT long filenames are invisible to OS/2, and EA long filenames are invisible to Windows.

FAT32
In order to overcome the size limit of FAT16, while at the same time allowing DOS (disk operating system) real mode code to handle the format, and without reducing available conventional memory unnecessarily, Microsoft expanded the cluster size yet again, calling the new revision FAT32. Cluster values are represented by 32-bit numbers, of which 28 bits are used to hold the cluster number. The boot sector uses a 32-bit field for the sector count, limiting the FAT32 volume size to 2 <abbr title="TeraByte (1024GB)">TB for sector size of 512 bytes and 16 <abbr title="TeraByte (1024GB)">TB for sector size of 4,096 bytes; compare the size limits given below.

FAT32 was introduced with Windows 95 OSR2, although reformatting was needed to use it, and DriveSpace 3 (the version that came with Windows 95 OSR2 and Windows 98) never supported it. Windows 98 introduced a utility to convert existing hard disks from FAT16 to FAT32 without loss of data. In the NT line, native support for FAT32 arrived in Windows 2000. A free FAT32 driver for Windows NT 4.0 was available from Winternals, a company later acquired by Microsoft. Since the acquisition the driver is no longer officially available.

The maximum possible size for a file on a FAT32 volume is 4 <abbr title="GigaByte (1024MB)">GB minus 1 byte or 4 294 967 295 (232−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. Larger files require another filesystem.

Future
For most purposes, the NTFS file system is superior to FAT in terms of features and reliability; its main drawbacks are the size overhead for small volumes and the very limited support by anything other than the NT-based versions of Windows, since the exact specification is a trade secret of Microsoft. The availability of NTFS-3G since mid 2006 has led to much improved NTFS support in Unix-like operating systems; however, many features provided by NTFS are still unavailable to non-Windows operating systems.

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. ←(Remove this line)

•DOS Floppy is erroneous, as a floppy can be formatted with other FS technologies, and DOS is not a FS technology. The need to boot to a DOS floppy was NEVER necessary. NT first used the ERD (Emergency Repair Disk), which provided a basic NT environment to perform rudimentary maintenance if NTFS was rendered unbootable.)

recovery console to work around, 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. ← (This entire section is dated information.)

• BartPE was NEVER necessary to repair NT or NTFS, as it is a full copy of NT that hackers use to subvert security on NTFS volumes. Legitimate repairs can be made with the Microsoft ERD that evolved to Windows NT PE 1.0 in WindowsXP which was a limited NT installation that provided custom repair utilities.

• Windows Vista and Windows 7 use NT PE 2.0 that is slim but full version of Windows NT that provides access to Win32/NT APIs and i not limited to the custom repair utilities that PE 1.0 provided. Thus PE 2.0 can run the same administrative tools that are normally available to the full NT OS.

• http://technet.microsoft.com/en-us/library/cc507857.aspx#E5G

• The idea that NTFS was 'hard' to repair or flawed because of its limited access from older boot and DOS methodologies were by design for security reasons, which is a feature of NTFS, not a flaw.

• The 'need' for a floppy disk is extremely outdated, as NT since version 4.0 has fully supported booting from a CD/DVD to access the ERD features for maintenance of the NTFS, making the original floppy NT based ERD an outdated concept.

(The original section sounds like it was written from a person locked into a DOS or UNIX modality where a 'floppy' is how to repair a damaged FS.)

FAT is still the normal file system for removable media (with the exception of CDs and DVDs), with FAT12 used on floppies, and FAT16 or FAT32 on most other removable media (such as flash memory cards for digital cameras and USB flash drives).

← Not accurate. NTFS is used and shipped by OEMs on the majority removable media drives with only smaller flash media using FAT32 that are shared with devices that are limited to FAT32/FATeX.

FATX
FATX is a slightly modified version of the FAT filesystem, and is designed for Microsoft's Xbox video game console hard disk drive and memory cards. On&#x2011;disk datestamps differ slightly between FAT and FATX: in FAT, the epoch is 1980; in FATX, the epoch is 2000. On the Xbox 360, the epoch is 1980.

exFAT
exFAT is an incompatible replacement for FAT file systems that was introduced with Windows Embedded CE 6.0. MBR partition type is 0x7 (the same as NTFS). exFAT is intended to be used on SDXC and flash drives, where FAT is used today.

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

A FAT file system is composed of four different sections.


 * 1) The Reserved sectors, located at the very beginning. The first reserved sector (sector 0) is the Boot Sector (aka Partition Boot Record). It includes an area called the BIOS Parameter Block (with some basic file system information, in particular its type, and pointers to the location of the other sections) and usually contains the operating system's boot loader code. The total count of reserved sectors is indicated by a field inside the Boot Sector. Important information from the Boot Sector is accessible through an operating system structure called the Drive Parameter Block in DOS and OS/2. For FAT32 file systems, the reserved sectors include a File System Information Sector at sector 1 and a Backup Boot Sector at Sector 6.
 * 2) The FAT Region. This typically contains two copies (may vary) of the File Allocation Table for the sake of redundancy checking, although the extra copy is rarely used, even by disk repair utilities. These are maps of the Data Region, indicating which clusters are used by files and directories. In FAT16 and FAT12 they immediately follow the reserved sectors.
 * 3) The Root Directory Region. This is a Directory Table that stores information about the files and directories located in the root directory. It is only used with FAT12 and FAT16, and imposes on the root directory a fixed maximum size which is pre-allocated at creation of this volume. FAT32 stores the root directory in the Data Region, along with files and other directories, allowing it to grow without such a constraint. Thus, for FAT32, the Data Region starts here.
 * 4) The Data Region. This is where the actual file and directory data is stored and takes up most of the partition. The size of files and subdirectories can be increased arbitrarily (as long as there are free clusters) by simply adding more links to the file's chain in the FAT. Note however, that files are allocated in units of clusters, so if a 1 kB file resides in a 32 kB cluster, 31 kB are wasted. FAT32 typically commences the Root Directory Table in cluster number 2: the first cluster of the Data Region.

FAT uses little endian format for entries in the header and the FAT(s). 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 &times; sectors per cluster), FATs (number of FATs &times; sectors per FAT), and hidden sectors including the boot sector &mdash; this would result in unused sectors at the end of the volume. If a partition contains more sectors than the total number of sectors occupied by the file system it would also result in unused sectors at the end of the volume.

Boot Sector
On non-partitioned devices, e.g., floppy disks, the boot sector is the first sector. For partitioned devices such as hard drives, the first sector is the Master Boot Record defining partitions, while the first sector of partitions formatted with a FAT file system is again the FAT boot sector.

Common structure of the first 36 bytes used by all FAT versions are:

A simple formula translates a given cluster number <tt>CN</tt> to a logical sector number <tt>LSN</tt>:
 * 1) Determine (once) , where the reserved sector count <tt>RSC</tt> is stored at offset 0x0E, the FAT number <tt>FN</tt> at offset 0x10, the sectors per FAT <tt>SF</tt> at offset 0x16 (FAT12/FAT16) or 0x24 (FAT32), the root directory entries <tt>RDE</tt> at offset 0x11, the sector size <tt>SS</tt> at offset 0x0B, and <tt>ceil(x)</tt> rounds up to a whole number.
 * 2) Determine , where the sectors per cluster <tt>SC</tt> are stored at offset 0x0D.

A translation of CHS to <tt>LSN</tt> is also simple:, where the sectors per track <tt>SPT</tt> are stored at offset 0x18, and the number of sides <tt>NOS</tt> at offset 0x1A. Track number <tt>TN</tt>, head number <tt>HN</tt>, and sector number <tt>SN</tt> correspond to Cylinder-head-sector &mdash; the formula gives the known CHS to LBA translation.

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

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

In essence FAT32 inserts 28 bytes, followed by the remaining 26 <abbr title="Extended BIOS Parameter Block">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 0x0B - 0x17 in the standard sector) were located at offset 0x50. Later versions of Apricot MS-DOS gained the ability to read and write disks with the standard boot sector in addition to those with the Apricot one.

DOS Plus on the BBC Master 512 did not use conventional boot sectors at all. Data disks omitted the boot sector and began with a single copy of the FAT (the first byte of the FAT was used to determine disk capacity) while boot disks began with a miniature ADFS file system containing the boot loader, followed by a single FAT. It could also access standard PC disks formatted to 180 kB or 360 kB, again using the first byte of the FAT to determine the capacity.

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

File Allocation Table
A partition is divided up into identically sized clusters, small blocks of contiguous space. Cluster sizes vary depending on the type of FAT file system being used and the size of the partition, typically cluster sizes lie somewhere between 2 kB and 32 kB. Each file may occupy one or more of these clusters depending on its size; thus, a file is represented by a chain of these clusters (referred to as a singly linked list). However these clusters are not necessarily stored adjacent to one another on the disk's surface but are often instead fragmented throughout the Data Region.

The File Allocation Table (FAT) is a list of entries that map to each cluster on the partition. Each entry records one of five things:
 * the cluster number of the next cluster in a chain
 * a special end of clusterchain (EOC) entry that indicates the end of a chain
 * a special entry to mark a bad cluster
 * a zero to note that the cluster is unused

The first two entries in a FAT store special values: The first entry contains a copy of the media descriptor (from boot sector, offset 0x15). The remaining 4 bits (if FAT12), 8 bits (if FAT16) or 20 bits (if FAT32) of this entry are 1.

The second entry stores the end-of-cluster-chain marker. The high order two bits of this entry are sometimes, in the case of FAT16 and FAT32, used for dirty volume management: high order bit 1: last shutdown was clean; next highest bit 1: during the previous mount no disk I/O errors were detected.

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

FAT entry values:

Note that FAT32 uses only 28 bits of the 32 possible bits. The upper 4 bits are usually zero (as indicated in the table above) but are reserved and should be left untouched.

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

Directory table
A directory table is a special type of file that represents a directory (also known as a folder). Each file or directory stored within it is represented by a 32-byte entry in the table. Each entry records the name, extension, attributes (archive, directory, hidden, read-only, system and volume), the date and time of creation, the address of the first cluster of the file/directory's data and finally the size of the file/directory. Aside from the Root Directory Table in FAT12 and FAT16 file systems, which occupies the special Root Directory Region location, all Directory Tables are stored in the Data Region. The actual number of entries in a directory stored in the Data Region can grow by adding another cluster to the chain in the FAT.

Note that before each entry there can be "fake entries" to support the Long File Name. (See further down the article).

Legal characters for DOS file names include the following:
 * Upper case letters <tt>A</tt>–<tt>Z</tt>
 * Numbers <tt>0</tt>–<tt>9</tt>
 * Space (though trailing spaces in either the base name or the extension are considered to be padding and not a part of the file name, also filenames with space in them could not be used on the DOS command line prior to Windows 95 because of the lack of a suitable escaping system)
 * <tt>! # $ % & ' - @ ^ _ ` { } ~ </tt>
 * Values 128–255

This excludes the following ASCII characters:
 * <tt>" * / : < > ? \ | </tt> Windows/MSDOS has no shell escape character
 * <tt>+, . ; = [ ]</tt> They are allowed in long file names only.
 * Lower case letters <tt>a</tt>–<tt>z</tt> Stored as <tt>A</tt>–<tt>Z</tt>. Allowed in long file names.
 * Control characters 0–31
 * Value 127 (DEL)

The DOS file names are in the current OEM character set &mdash; 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 <abbr title="CHange Code Page">CHCP ) with respect to lower and upper case, sorting, or validity as file name character.

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

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

Older versions of PC-DOS mistake LFN names in the root directory for the volume label, and are likely to display an incorrect label.

Each phony entry can contain up to 13 UTF-16 characters (26 bytes) by using fields in the record which contain file size or time stamps (but not the starting cluster field, for compatibility with disk utilities, the starting cluster field is set to a value of 0. See 8.3 filename for additional explanations). Up to 20 of these 13-character entries may be chained, supporting a maximum length of 255 UTF-16 characters.

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

LFN entries use the following format:

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

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

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 <tt>"README&#x2420;&#x2420;TXT"</tt>.)

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 "<tt>example.TXT</tt>" or "<tt>HELLO.txt</tt>" but not "<tt>Mixed.txt</tt>". Few other operating systems support it. This creates a backwards-compatibility problem with older Windows versions (95, 98, ME) that see all-uppercase filenames if this extension has been used, and therefore can change the name of a file when it is transported between OSes, such as on a USB flash drive. Current 2.6.x versions of Linux will recognize this extension when reading (source: kernel 2.6.18 /fs/fat/dir.c and fs/vfat/namei.c); the mount option shortname determines whether this feature is used when writing.

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

Size limits
The FAT12, FAT16 (incl. BigFAT), and FAT32 variants of the FAT file systems have clear limits based on the number of clusters and the number of sectors per cluster (1, 2, 4, ..., 128). For the typical value of 512 bytes per sector: FAT12    1 .. 4084 clusters:  1 .. 12 FAT sectors FAT16 4085 .. 65524 clusters: 16 .. 256 FAT sectors FAT32 65525 .. 268435444 clusters: 512 .. 2097152 FAT sectors FAT12 min.:   1 *         1                  512 (  0.5 KB) FAT16 min.:   1 *      4085            2,091,520 ( 2043 KB) FAT32 min.:   1 *     65525           33,548,800 (32763 KB) FAT12 max.:  64 *      4084          133,824,512 (~ 127 MB) [FAT12 max.: 128 *      4084          267,694,024 (~ 255 MB)] FAT16 max.:  64 *     65524        2,147,090,432 (~2047 MB) [FAT16 max.: 128 *     65524        4,294,180,864 (~4095 MB)] FAT32 max.:   8 * 268435444    1,099,511,578,624 (~1024 GB) FAT32 max.:  16 * 268173557    2,196,877,778,944 (~2046 GB) [FAT32 max.:  32 * 134152181    2,197,949,333,504 (~2047 GB)] [FAT32 max.:  64 *  67092469    2,198,486,024,192 (~2047 GB)] [FAT32 max.: 128 *  33550325    2,198,754,099,200 (~2047 GB)]

Legend: 268435444+3 is hex. <tt>0FFF FFF7</tt>, because FAT32 version 0 uses only 28 bits in the 32bit cluster numbers, cluster numbers hex. <tt>0FFF FFF7</tt> up to <tt>0FFF FFFF</tt> 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 hex. <tt>FFF7</tt> for FAT16, and 4084+3 is hex. <tt>FF7</tt> for FAT12. The number of sectors per cluster is a power of 2 fitting in a single byte, the smallest value is 1 (hex. <tt>01</tt>), the biggest value is 128 (hex. <tt>80</tt>). 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 32bits (4 bytes) the maximal number of clusters (268435444) requires 2097152 FAT sectors for a sector size of 512 bytes. 2097152 is hex. <tt>200000</tt>, and storing this value needs more than two bytes. Therefore FAT32 introduced a new 32bit value in the FAT32 boot sector immediately following the 32bit value for the total number of sectors introduced in the "BigFAT" variant of FAT16.

The boot record extensions introduced with DOS 4.0 start with a magic 40 (hex. <tt>28</tt>) or 41 (hex. <tt>29</tt>). Typically FAT drivers look only at the number of clusters to distinguish FAT12, FAT16, and FAT32 &mdash; 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 <abbr title="remove directory">rd  command removes the initial "." (this directory) and ".." (parent directory) entries in subdirectories directly, therefore sector size 32 on a RAM disk is possible for FAT12, but requires 2 or more sectors per cluster. A FAT12 boot sector without the DOS 4 extensions needs 29 bytes before the first unnecessary "BigFAT" 32bit number of hidden sectors, this leaves three bytes for the (on a RAM disk unused) boot code and the magic hex. 55AA at the end of all boot sectors. On Windows NT the smallest supported sector size is 128.

On Windows NT operating systems the format command options  and   correspond to the maximal cluster size hex. <tt>80</tt> (128) with a sector size 1024 and 2048, respectively. For the common sector size 512  yields 128 sectors per cluster.

Fragmentation
The FAT file system does not contain mechanisms which prevent newly written files from becoming scattered across the partition. Other file systems, e.g., HPFS, use free space bitmaps that indicate used and available clusters, which could then be quickly looked up in order to find free contiguous areas. Another solution is the linkage of all free clusters into one or more lists (as is done in Unix file systems). Instead, the FAT has to be scanned as an array to find free clusters, which can lead to performance penalties with large disks.

In fact, computing free disk space on FAT is one of the most resource intensive operations, as it requires reading the entire FAT linearly. A possible justification suggested by Microsoft's Raymond Chen for limiting the maximum size of FAT32 partitions created on Windows was the time required to perform a "DIR" operation, which always displays the free disk space as the last line. Displaying this line took longer and longer as the number of clusters increased.

Some of the perceived problems with fragmentation of FAT file systems result from limitations of the device drivers.

The single-tasking DOS and the traditionally single-tasking PC hard disk architecture (only 1 outstanding input/output request at a time, no DMA transfers) did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks.

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

Modern operating systems have introduced these optimizations to FAT partitions, but optimizations can still produce unwanted artifacts in case of a system crash. A Windows NT system will allocate space to files on FAT in advance, selecting large contiguous areas, but in case of a crash, files which were being appended will appear larger than they were ever written into, with dozens of random kilobytes at the end.

With the large cluster sizes, 4 or 8K, forced by larger FAT32 partitions, the external fragmentation becomes somewhat less significant, and internal fragmentation, i.e. disk space waste (since files are rarely exact multiples of cluster size), starts to be a problem as well, especially when there are a great many small files.

Third-party support
Due to the widespread use of FAT formatted media since its introduction many operating systems have provided support for FAT and subsequently VFAT and FAT32 through official or third-party file system handlers. For example, Linux, FreeBSD, BeOS and JNode provide inbuilt support for FAT. Early Linux distributions also supported a format known as UMSDOS, a FAT variant with Unix file attributes (such as long file name and access permissions) stored in a separate file called “<tt>--linux-.---</tt>”. UMSDOS fell into disuse after VFAT was released and it is not enabled by default in Linux kernels from version 2.5.7 onwards. Mac OS 9 and Mac OS X also support FAT file systems on volumes other than the boot disk. AmigaOS supports FAT through the CrossDOS file system.

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

FAT and Alternate Data Streams
The FAT file system itself is not designed for supporting Alternate Data Streams (ADS), but some operating systems that heavily depend on them have devised various methods for handling them in FAT drives. Such methods either store the additional information in extra files and directories (Mac OS), or give new semantics to previously unused fields of the FAT on-disk data structures (OS/2 and Windows NT).

Mac OS using PC Exchange stores its various dates, file attributes and long filenames in a hidden file called FINDER.DAT, and resource forks (a common Mac OS ADS) in a subdirectory called RESOURCE.FRK, in every directory where they are used. From PC Exchange 2.1 onwards, they store the Mac OS long filenames as standard FAT long filenames and convert FAT filenames longer than 31 characters to unique 31-character filenames, which can then be made visible to Macintosh applications.

Mac OS X stores resource forks and metadata (file attributes, other ADS) in a hidden file with a name constructed from the owner filename prefixed with "._", and Finder stores some folder and file metadata in a hidden file called ".DS Store".

OS/2 heavily depends on extended attributes (EAs) and stores them in a hidden file called "EA DATA. SF" in the root directory of the FAT12 or FAT16 volume. This file is indexed by 2 previously reserved bytes in the file's (or directory's) directory entry. In the FAT32 format, these bytes hold the upper 16 bits of the starting cluster number of the file or directory, hence making it difficult to store EAs on FAT32. Extended attributes are accessible via the Workplace Shell desktop, through REXX scripts, and many system GUI and command-line utilities (such as 4OS2).

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

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

Licensing
Microsoft applied for, and was granted, a series of patents for key parts of the FAT file system in the mid-1990s. Being almost universally compatible and well-understood, FAT is frequently chosen as an interchange format for flash media used in digital cameras and PDAs.

On December 3, 2003 Microsoft announced 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:
 * - Method and system for accessing a file using file names having different file name formats. Filed July 6, 1992. This covered a means of generating and associating a short, 8.3 filename with long one (for example, "Microsoft.txt" with "MICROS~1.TXT") and a means of enumerating conflicting short filenames (for example, "MICROS~2.TXT" and "MICROS~3.TXT"). It is unclear whether this patent would cover an implementation of FAT without explicit long filename capabilities. Hard links in Unix file systems do not appear to be prior art: deleting a FAT file via its long name will also remove its short name. Renaming a file to a "short" name also updates the long file name for coherency; similarly, renaming a file to a "long" name will allocate a new "short" name. In NTFS, hard links and dual names are separate concepts and each hard link has two names. Finally, at the API level, both names are always provided together when a directory lookup is requested from the system; they do not appear as two separate files and do not have to be "matched" to determine unique files.
 * - 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 and . This decision was later overturned by the Patent Office on 2006-01-10.
 * - 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.
 * - Method and system for providing a common name space for long and short file names in an operating system. Filed on 1997-01-28. This makes claims on the methods used when Windows 95, Windows 98 and Windows Me expose long filenames to their MS-DOS compatibility layer. It does not appear to affect any non-Microsoft FAT implementations.

Many technical commentators have concluded that these patents only cover FAT implementations that include support for long filenames, and that removable solid-state media and consumer devices only using short names would be unaffected.

Additionally, in the 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:
 * - System for accessing extended object attribute (EA) data through file name or EA handle linkages in path tables. Filed on 1990-09-25 by Barry A. Feigenbaum and Felix Miro of IBM, this makes claims on the methods used by OS/2, Windows NT, and Linux for storing extended attribute data in the "EA DATA. SF" file.

Appeal
As there was widespread call for these patents to be re-examined, the Public Patent Foundation (PUBPAT) submitted evidence to the US Patent and Trade Office (USPTO) disputing the validity of these patents, including prior art references from Xerox and IBM. The USPTO acknowledged that the evidence raised "substantial new question[s] of patentability," and opened an investigation into the validity of Microsoft's FAT patents.

On 2004-09-30 the USPTO rejected all claims of, 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 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 filesystem. As some TomTom products are based on Linux, this marked the first time that Microsoft tried to enforce its patents against the Linux platform. The lawsuit was settled out of court the following month with an agreement that Microsoft be given access to four of TomTom's patents, that TomTom will drop support for the FAT32 filesystem from its products, and that in return Microsoft not seek legal action against TomTom for the five year duration of the settlement agreement.

In October 2010, Microsoft filed a patent infringement lawsuit against Motorola alleging several patents (including two of the FAT32 filesystem patents) were not licensed for use in the Android operating system. They also submitted a complaint to the ITC.

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