|Full Name||File Allocation Table|
|(12-bit version)||(16-bit version)||(32-bit version)|
|Introduced||1980 (Seattle QDOS)||November 1987, (Compaq DOS 3.31)||August 1996 (Windows 95 OSR2)|
|Partition identifier||0x01 (MBR)||0x04, 0x06, 0x0E (MBR)|| 0x0B, 0x0C (MBR) |
|File allocation||Linked List|
|Bad blocks||Cluster tagging|
|Max file size||4 GB − 1 byte (or volume size if smaller)|
|Max cluster count||4,077 (212-19)||65,517 (216-19)||268,435,437 (228-19)|
|Max filename size||8.3 filename, or 255 UTF-16 characters when using LFN|
|Max volume size||32 MB|| 2 GB|
4 GB with 64k clusters (not widely supported)
| 2 TB|
8 TB (2-KB sector)
|Dates recorded|| Creation, modified, access (accuracy to day only)|
(Creation time and access date are only available when LFN support is enabled)
|Date range||January 1, 1980 - December 31, 2107|
|Attributes||Read-only, hidden, system, volume label, subdirectory, archive|
|Transparent compression||Per-volume, Stacker, DoubleSpace, DriveSpace||No|
|Transparent encryption||Per-volume only with DR-DOS||No|
File Allocation Table or FAT is a computer file system architecture originally developed by Bill Gates and Marc McDonald in 1976/1977. It is the primary file system for various operating systems including DR-DOS, OpenDOS, freeDOS, MS-DOS, OS/2(v1.1), and Microsoft Windows (up to Windows Me). For floppy disks (FAT12 and FAT16 without long filename support) it has been standardized as ECMA-107 and ISO/IEC 9293. The use of long filenames with FAT is patented in part.
The FAT file system is relatively straightforward and is supported by virtually all existing operating systems for personal computers. This makes it an ideal format for solid-state memory cards and a convenient way to share data between operating systems.
Common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing slower on storage devices which have higher seek time for random data access (Such as mechanical hard drives). Manually-invoked periodic defragmentation is one solution to this problem, but is often a lengthy process, and unwise in some instances. Due to a limited number of lifetime writes, and their quick access times, solid-state memory cards should usually not be defragmented.
The name originates from the usage of a table which centralizes the information about which areas belong to files, are free or possibly unusable, and where each file is stored on the disk. To limit the size of the table, disk space is allocated to files in contiguous groups of hardware sectors called clusters. As disk drives have evolved, the maximum number of clusters has dramatically increased, and so the number of bits to identify a cluster has grown. The successive major versions of the FAT format are named after the number of table element bits: 12, 16, and 32. The FAT standard has also been expanded in other ways while preserving backward compatibility with existing software.
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 diskette from being usable. The DOS formatting tool rejected such diskettes completely. Bad sectors were allowed only in the file area, where they made the entire holding cluster unusable as well. FAT12 remains in use on 1.44MB floppy disks.
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 FAT. This probably prompted a dubious optimization of the cluster size, which went down from 2 sectors to just 1. The net effect was that high density diskettes were significantly slower than older double density ones.
To allow the use of more FAT partitions in a compatible way, a new partition type was introduced (in MS-DOS 3.2, January 1986), the extended partition; which is a container for additional partitions called logical drives. Originally only one logical drive was possible, permitting hard disks up to 64 MB. In MS-DOS 3.3 (August 1987) this limit was increased to 24 drives; it probably came from the compulsory letter-based disk naming (A and B being reserved for the two floppy drives, with which many, if not most, systems of the era were equipped). Logical drives are described by on-disk structures which closely resemble the Master Boot Record (MBR) of the disk (which describes the primary partitions), likely to simplify the implementation. Though some believe these partitions were nested in a way analogous to Russian matryoshka dolls, that isn't the case. They are stored as a row of separate blocks within a single box; these blocks are often referred to as being chained together, by the links in their extended boot record (EBR) sectors. Only one extended partition is allowed. Logical drives are not bootable, and the extended partition can only be created after the primary FAT partition (except with third party formatting tools), which remove all ambiguity, but also the possibility of booting several DOS versions from the same hard disk.
A useful side-effect of the extended partition scheme was to significantly increase the maximum number of partitions possible on a PC hard disk beyond the four which could be described by the MBR alone.
Prior to the introduction of extended partitions, some hard disk controllers (which at that time were separate option boards, since the IDE standard did not yet exist) could make large hard disks appear as two separate disks.
In 1988 the improvement became more generally available through MS-DOS 4.0 and OS/2 1.1. The limit on partition size was dictated by the 8-bit signed count of sectors-per-cluster, which had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 partition size at 2 gigabytes. On magneto-optical media, which can have 1 or 2 KB sectors, the limit is proportionally greater.
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.
The number of root directory entries available is determined when the volume is formatted, and is stored in a 16-bit signed field setting an absolute limit of 32767 entries (32736, a multiple of 32, in practice). For historical reasons, FAT12 and FAT16 media generally use 512 root directory entries on non-floppy media. Other sizes may be incompatible with some software or devices (entries being file and/or folder names in the original 8.3 format). Some third party tools like mkdosfs allow the user to set this parameter.
Interestingly, the VFAT driver actually appeared before Windows 95, in Windows for Workgroups 3.11, but was only used for implementing 32-bit File Access, a higher performance protected mode file access method, bypassing DOS and directly using either the BIOS, or, better, the Windows-native protected mode disk drivers.
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.
On Windows 95/98, due to the version of Microsoft's SCANDISK utility included with these operating systems being a 16-bit application, the FAT structure is not allowed to grow beyond around 4.2 million (< 222) clusters, placing the volume limit at 127.53 gigabytes. A limitation in original versions of Windows 98/98SE's Fdisk utility causes it to incorrectly report disk sizes over 64GB. A corrected version is available from Microsoft. These limitations do not apply to Windows 2000/XP except during Setup, in which there is a 32GB limit. Windows Me supports the FAT32 file system without any limits. However, similarly to Windows 95/98/98SE there is no native support for 48bit LBA in Windows ME, meaning that the maximum disk size is 127.6GB
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.
Windows 2000 and Windows XP can read and write to FAT32 file systems of any size, but the format program included in Windows 2000 and higher can only create FAT32 file systems of 32 GB or less. This limitation is by design and according to Microsoft was imposed because many tasks on a very large FAT32 file system become slow and inefficient. This limitation can be bypassed by using third-party formatting utilities or by using the built-in FORMAT.EXE command-line utility.
The maximum possible size for a file on a FAT32 volume is 4 GB minus 1 "null" byte (232−1 bytes). Video applications, large databases, and some other software easily exceed this limit. Larger files require another formatting type such as HFS+ or NTFS. Until mid-2006, those who run dual boot systems or who move external data drives between computers with different operating systems had little choice but to stick with FAT32. Since then, full support for NTFS has become available in Linux and many other operating systems, by installing the FUSE library (on Linux) together with the NTFS-3G driver. Data exchange is also possible between Windows and Linux by using the Linux-native ext2 or ext3 file systems through the use of external drivers for Windows, such as ext2 IFS; however, Windows cannot boot from ext2 or ext3 partitions.
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.
The High Performance File System (HPFS) divides disk space into bands, which have their own free space bitmap, where multiple files opened for simultaneous write could be expanded separately.
Some of the perceived problems with fragmentation resulted from operating system and hardware limitations.
The single-tasking DOS and the traditionally single-tasking PC hard disk architecture (only 1 outstanding input/output request at a time, no DMA transfers) did not contain mechanisms which could alleviate fragmentation by asynchronously prefetching next data while the application was processing the previous chunks.
Similarly, write-behind caching was often not enabled by default with Microsoft software (if present) given the problem of data loss in case of a crash, made easier by the lack of hardware protection between applications and the system.
MS-DOS also did not offer a system call which would allow applications to make sure a particular file has been completely written to disk in the presence of deferred writes (cf. fsync in Unix or DosBufReset in OS/2). Disk caches on MS-DOS were operating on disk block level and were not aware of higher-level structures of the file system. In this situation, cheating with regard to the real progress of a disk operation was most dangerous.
Modern operating systems have introduced these optimizations to FAT partitions, but optimizations can still produce unwanted artifacts in case of a system crash. A Windows NT system will allocate space to files on FAT in advance, selecting large contiguous areas, but in case of a crash, files which were being appended will appear larger than they were ever written into, with dozens of random kilobytes at the end.
With the large cluster sizes, 16 or 32K, forced by larger FAT32 partitions, the external fragmentation becomes somewhat less significant, and internal fragmentation, ie. 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.
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").
Since Microsoft has announced the discontinuation of its MS-DOS-based consumer operating systems with Windows Me, it remains unlikely that any new versions of FAT will appear. For most purposes, the NTFS file system that was developed for the Windows NT line is superior to FAT from the points of view of efficiency, performance, 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, which in turn makes it difficult to use a DOS floppy for recovery purposes. Microsoft provided a recovery console to work around this issue, but for security reasons it severely limited what could be done through the Recovery Console by default. The movement of recovery utilities to boot CDs based on BartPE or Linux (with NTFS-3G) is finally eroding this drawback.
FAT is still the normal file system for removable media (with the exception of CDs and DVDs), with FAT12 used on floppies, and FAT16 on most other removable media (such as flash memory cards for digital cameras and USB flash drives). Most removable media are not yet large enough to benefit from FAT32, although some larger flash drives, like SDHC, do make use of it. FAT16 is used on these drives for reasons of compatibility and size overhead.
The FAT32 formatting support in Windows 2000 and XP is limited to volumes of 32 GB, which effectively forces users of modern hard drives either to use NTFS, to partition the drive into smaller volumes (below 32 GB), or to format the drive using third party tools.
exFAT is an incompatible replacement for FAT file systems that was introduced with Windows Embedded CE 6.0. It is intended to be used on flash drives, where FAT is used today. Windows XP file system drivers will be offered by Microsoft shortly after the release of Windows CE 6.0, while Windows Vista Service Pack 1 added exFAT support to Windows Vista. exFAT introduces a free space bitmap allowing faster space allocation and faster deletes, support for files up to 264 bytes, larger cluster sizes (up to 32 MB in the first implementation), an extensible directory structure and name hashes for filenames for faster comparisons. It does not have short 8.3 filenames anymore. It does not appear to have security access control lists or file system journaling like NTFS, though device manufacturers can choose to implement simplified support for transactions (backup file allocation table used for the write operations, primary FAT for storing last known good allocation table).
The following is an overview of the order of structures in a FAT partition or disk:
| More reserved|
| Data Region (for files and directories) ...|
(To end of partition or disk)
A FAT file system is composed of four different sections.
FAT uses little endian format for entries in the header and the FAT(s).
Common structure of the first 36 bytes used by all FAT versions:
|Byte Offset||Length (bytes)||Description|
|0x00||3||Jump instruction. This instruction will be executed and will skip past the rest of the (non-executable) header if the partition is booted from. See Volume Boot Record. If the jump is two-byte near jmp it is followed by a NOP instruction.|
|0x03||8||OEM Name (padded with spaces). MS-DOS checks this field to determine which other parts of the boot record can be relied on. Common values are |
|0x0b||2||Bytes per sector. A common value is 512, especially for file systems on IDE (or compatible) disks. The BIOS Parameter Block starts here.|
|0x0d||1||Sectors per cluster. Allowed values are powers of two from 1 to 128. However, the value must not be such that the number of bytes per cluster becomes greater than 32 KB.|
|0x0e||2||Reserved sector count. The number of sectors before the first FAT in the file system image. Should be 1 for FAT12/FAT16. Usually 32 for FAT32.|
|0x10||1||Number of file allocation tables. Almost always 2.|
|0x11||2||Maximum number of root directory entries. Only used on FAT12 and FAT16, where the root directory is handled specially. Should be 0 for FAT32. This value should always be such that the root directory ends on a sector boundary (i.e. such that its size becomes a multiple of the sector size). 224 is typical for floppy disks.|
|0x13||2||Total sectors (if zero, use 4 byte value at offset 0x20)|
|0x15||1||Media descriptor |
|0x16||2||Sectors per File Allocation Table for FAT12/FAT16|
|0x18||2||Sectors per track|
|0x1a||2||Number of heads|
|0x20||4||Total sectors (if greater than 65535; otherwise, see offset 0x13)|
Further structure used by FAT12 and FAT16, also known as Extended BIOS Parameter Block:
|Byte Offset||Length (bytes)||Description|
|0x24||1||Physical drive number|
|0x25||1||Reserved ("current head")|
|0x26||1||Extended boot signature. Value is 0x29 or 0x28.|
|0x27||4||ID (serial number)|
|0x36||8||FAT file system type, padded with blanks (0x20), e.g.: "FAT12 ", "FAT16 ". This is not meant to be used to determine drive type, however, some utilities use it in this way.|
|0x3e||448||Operating system boot code|
|0x1FE||2||Boot sector signature (0x55 0xAA)|
The boot sector is portrayed here as found on e.g. an OS/2 1.3 boot diskette. Earlier versions used a shorter BIOS Parameter Block and their boot code would start earlier (for example at offset 0x2b in OS/2 1.1).
Further structure used by FAT32:
|Byte Offset||Length (bytes)||Description|
|0x24||4||Sectors per file allocation table|
|0x2c||4||Cluster number of root directory start|
|0x30||2||Sector number of FS Information Sector|
|0x32||2||Sector number of a copy of this boot sector|
|0x40||1||Physical Drive Number|
|0x42||1||Extended boot signature.|
|0x43||4||ID (serial number)|
|0x52||8||FAT file system type: "FAT32 "|
|0x5a||420||Operating system boot code|
|0x1FE||2||Boot sector signature (0x55 0xAA)|
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 capacity.
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:
Each version of the FAT file system uses a different size for FAT entries. The size is indicated by the name, for example the FAT16 file system uses 16 bits for each entry while the FAT32 file system uses 32 bits. Only 28 of these are actually used, however. This difference means that the File Allocation Table of a FAT32 system can map a greater number of clusters than FAT16, allowing for larger partition sizes with FAT32. This also allows for more efficient use of space than FAT16, because on the same hard drive a FAT32 table can address smaller clusters which means less wasted space.
FAT entry values:
|0x001||0x0001||0x?0000001||Reserved value; do not use|
|0x002 - 0xFEF||0x0002 - 0xFFEF||0x?0000002 - 0x?FFFFFEF||Used cluster; value points to next cluster|
|0xFF0 - 0xFF6||0xFFF0 - 0xFFF6||0x?FFFFFF0 - 0x?FFFFFF6||Reserved values; do not use.|
|0xFF7||0xFFF7||0x?FFFFFF7||Bad sector in cluster or reserved cluster|
|0xFF8 - 0xFFF||0xFFF8 - 0xFFFF||0x?FFFFFF8 - 0x?FFFFFFF||Last cluster in file|
Note that 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. In the table above these are denoted by a question mark.
The first cluster of the Data Region is cluster #2. That leaves the first two entries of the FAT unused. In the first byte of the first entry a copy of the media descriptor is stored. The remaining 8 bits (if FAT16), or 20 bits (if Fat32) of this entry are 1. In the second entry the end-of-cluster-chain marker is stored. The high order two bits of the second 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.
Legal characters for DOS file names include the following:
This excludes the following ASCII characters:
The DOS file names are in the OEM character set.
Directory entries, both in the Root Directory Region and in subdirectories, are of the following format:
|0x00||8||DOS file name (padded with spaces) The first byte can have the following special values:
|0x08||3||DOS file extension (padded with spaces)|
|0x0b||1||File Attributes The first byte can have the following special values:
|0x0c||1||Reserved; two bits are used by NT and later versions to encode case information (see below); otherwise 0|
|0x0d||1||Create time, fine resolution: 10ms units, values from 0 to 199.|
|0x0e||2||Create time. The hour, minute and second are encoded according to the following bitmap: |
|0x10||2||Create date. The year, month and day are encoded according to the following bitmap: |
|0x12||2||Last access date; see offset 0x10 for description.|
|0x14||2||EA-Index (used by OS/2 and NT) in FAT12 and FAT16, High 2 bytes of first cluster number in FAT32|
|0x16||2||Last modified time; see offset 0x0e for description.|
|0x18||2||Last modified date; see offset 0x10 for description.|
|0x1a||2||First cluster in FAT12 and FAT16. Low 2 bytes of first cluster in FAT32. Entries with the Volume Label flag, subdirectory ".." pointing to root, and empty files with size 0 should have first cluster 0.|
|0x1c||4||File size. Entries with the Volume Label or Subdirectory flag set should have a size of 0.|
Clusters are numbered from a cluster offset as defined above. That is, a zero in 0x1a would mean the first data segment is at:
reservedSectors + (noofFAT * sectors2FAT) + (maxRootEntry * 32 / bytes2sector) -2;
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. Other not used characters are filled with 0xFF 0xFF.
LFN entries use the following format:
|0x01||10||Name characters (five UTF-16 characters)|
|0x0b||1||Attributes (always 0x0F)|
|0x0c||1||Reserved (always 0x00)|
|0x0d||1||Checksum of DOS file name|
|0x0e||12||Name characters (six UTF-16 characters)|
|0x1a||2||First cluster (always 0x0000)|
|0x1c||4||Name characters (two UTF-16 characters)|
If there are multiple LFN entries, required to represent a file name, firstly comes the last LFN entry (the last part of the filename). The sequence number here also has bit 7 (0x40) checked (this means the last LFN entry. However it's the first entry got when reading the directory file). The last LFN entry has the biggest sequence number which decreases in following entries. The first LFN entry has sequence number 1. Bit 8 (0x80) of the sequence number is used to indicate that the entry is deleted.
For example if we have filename "File with very long filename.ext" it would be formatted like this:
|Sequence number||Entry data|
|0x02||"y long filena"|
|0x01||"File with ver"|
|???||Normal 8.3 entry|
A checksum also allows verification of whether a long file name matches the 8.3 name; such a mismatch could occur if a file was deleted and re-created using DOS in the same directory position. The checksum is calculated using the algorithm below. (Note that pFcbName is a pointer to the name as it appears in a regular directory entry, i.e. the first eight characters are the filename, and the last three are the extension. The dot is implicit. Any unused space in the filename is padded with spaces (ASCII 0x20) char. For example, "Readme.txt" would be "README TXT".)
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 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 this. 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, 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.
|0x0C||2||RISC OS||File type, 0x000 - 0xFFF|
|0x0C||1||DOS Plus||User-defined file attributes F1-F4 |
|0x0D||1||DR-DOS||For a deleted file, the original first character of the filename.|
|0x0E||2||DR-DOS and FlexOS||Encrypted file password|
|0x0E||2||ANDOS||File address in the memory|
|0x10||4||DR-DOS 7||For a deleted file, its original file time and date; deleted files have their normal time and date fields set to the time of deletion|
|0x12||2||DR-DOS 6 and FlexOS||File owner ID|
|0x14||2||DR-DOS and FlexOS||File permissions bitmap (execute permissions are only used by FlexOS): |
On 2003-12-03 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:
Many technical commentators have concluded that these patents only cover FAT implementations that include support for long filenames, and that removable solid state media and consumer devices only using short names would be unaffected.
Additionally, in the document "Microsoft Extensible Firmware Initiative FAT 32 File System Specification, FAT: General Overview of On-Disk Format" published by Microsoft (version 1.03, 2000-12-06), Microsoft specifically grants a number of rights, which many readers have interpreted as permitting operating system vendors to implement FAT.
Microsoft is not the only company to have applied for patents for parts of the FAT file system. Other patents affecting FAT include:
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 reexamination, 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.