File Allocation Table

From Free net encyclopedia

	FAT12	FAT16	FAT32
Developer	Microsoft
Full Name	File Allocation Table
	(12-bit version)	(16-bit version)	(32-bit version)
Introduced	1977 (Microsoft Disk BASIC)	July 1988 (MS-DOS 4.0)	August 1996 (Windows 95 OSR2)
Partition identifier	0x01 (MBR)	0x04, 0x06, 0x0E (MBR)	0x0B, 0x0C (MBR) EBD0A0A2-B9E5-4433 -87C0-68B6B72699C7 (GPT)
Structures	FAT12	FAT16	FAT32
Directory contents	Table
File allocation	Linked List
Bad blocks	Linked List
Limits	FAT12	FAT16	FAT32
Max file size	32 MiB	2 GiB	4 GiB
Max number of files	4,077	65,517	268,435,437
Max filename size	8.3 or 255 characters when using LFNs
Max volume size	32 MiB	2 GiB	8 TiB
Features	FAT12	FAT16	FAT32
Dates recorded	Creation, modified, access
Date range	January 1, 1980 - December 31, 2107
Forks	Not natively
Attributes	Read-only, hidden, system, volume label, subdirectory, archive
Permissions	No
Transparent compression	Per-volume, Stacker, DoubleSpace, DriveSpace		No
Transparent encryption	Per-volume only with DR-DOS		No

File Allocation Table (FAT) is a patentedTemplate:Ref file system developed by Microsoft for MS-DOS and is the primary file system for consumer versions of Microsoft Windows up to and including Windows Me.

The FAT file system is considered relatively uncomplicated, and is consequently supported by virtually all existing operating systems for personal computers. This ubiquity makes it an ideal format for floppy disks and solid-state memory cards, and a convenient way of sharing data between disparate operating systems installed on the same computer (a multiboot environment).

The most common implementations have a serious drawback in that when files are deleted and new files written to the media, their fragments tend to become scattered over the entire media making reading and writing a slow process. De-fragmentation is one solution to this, but is often a lengthy process in itself and has to be repeated regularly to keep the FAT file system clean.

Contents 1 History 1.1 FAT12 1.2 Directories 1.3 Initial FAT16 1.4 Extended partition and logical drives 1.5 Final FAT16 1.6 Long File Names (VFAT, LFNs) 1.7 FAT32 1.8 Third party support 1.9 FAT and Alternate Data Streams 1.10 Future 2 Design 2.1 Main disk structures 2.2 Boot Sector 2.2.1 Exceptions 2.3 File Allocation Table 2.4 Directory table 2.4.1 Third-party extensions 3 FAT licensing 3.1 Appeal 4 Footnotes 5 References 6 See also 7 External links

History

The FAT filesystem uses software methods that had been in use years prior to its formalization and was created by Bill Gates and Marc McDonald in 1977 for managing disks in Microsoft Disk BASIC and was incorporated by Tim Paterson in August 1980 to his 86-DOS operating system for the S-100 8086 CPU boards; the filesystem was the main difference between 86-DOS and CP/M, of which 86-DOS was otherwise mostly a clone.<ref>Duncan, Ray (1989). Design goals and implementation of the new High Performance File System. Microsoft Systems Journal 4 (5).</ref>

FAT12

This initial version of FAT is now referred to as FAT12. As a filesystem for floppy disks, it had a number of limitations: no support for hierarchical directories, cluster addresses were "only" 12-bits long (which made the code manipulating the FAT a bit tricky) and the disk size was stored as a 16-bit count of sectors, which limited the size to 32MB.

An entry-level diskette at the time would be 5.25", single-sided, 40 tracks, with 8 sectors per track, resulting in a capacity of slightly less than 160KB. The above limits exceeded this capacity by one or more orders of magnitude and at the same time allowed to fit all the control structures inside the first track, thus avoiding head movement during read and write operations. The limits were successively lifted in the following years.

Since the sole root directory had to fit inside the first track as well, the maximum possible number of files was limited to a few dozens.

Directories

In order to properly support the newer IBM PC XT computer, which featured a 10 MB hard disk, MS-DOS 2.0 was released around the same time, at the beginning of 1983, and introduced hierarchical directories. Apart from allowing for better organisation of files, directories allowed it to store many more files on the hard disk, as the maximum number of files was no longer constrained by the (still fixed) root directory size. This number could now be equal to the number of clusters (or even greater, given that zero-sized files do not use any clusters on FAT).

The format of the FAT itself did not change. The 10 MB hard disk on the PC XT had 4 KB clusters. If a 20 MB hard disk was later installed, and formatted with MS-DOS 2.0, the resultant cluster size would be 8 KB, the boundary at 15.9 MB.

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 a greater number of clusters (up to 65,517) and consequently much greater filesystem sizes. However, the maximum possible number of sectors and the maximum (partition, rather than disk) size of 32 MB did not change. Therefore, although technically already "FAT16", this format was not yet what today is commonly understood under this name. A 20 MB hard disk formatted under MS-DOS 3.0, was not accessible by the older MS-DOS 2.0. Of course, MS-DOS 3.0 could still access MS-DOS 2.0 style 8 KB cluster partitions.

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.

Extended partition and logical drives

Apart from improving the structure of the FAT filesystem itself, a parallel development allowing an increase in the maximum possible FAT storage space was the introduction of disk partitions. PC hard disks can only have up to 4 primary partitions, due to the fixed structure of the partition table in the master boot record (MBR). However, by design choice DOS would only use the partition marked as active, which was also the one the MBR would boot. It was not possible to create multiple primary DOS partitions using DOS tools, and third party tools would warn that such a scheme would not be compatible with DOS.

To allow the use of more partitions in a compatible way a new partition type was introduced (in MS-DOS 3.2, January 1986), the extended partition, which was actually just a container for additional partitions called logical drives. Originally only 1 logical drive was possible, allowing the use of 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 C: - Z: disk naming. The logical drives were described by on-disk structures which closely resemble MBRs, probably to simplify coding, and they were chained/nested in a way analogous to Russian matryoshka dolls. Only one extended partition was allowed.

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. Alternatively, special software drivers, like Ontrack's [1]'s Disk Manager could be installed for the same purpose

Final FAT16

Finally in November 1987, in Compaq DOS 3.31, came what is today called the FAT16 format, with the expansion of the 16-bit disk sector index to 32 bits. The result was initially called the DOS 3.31 Large File System. Although the on-disk changes were apparently minor, the entire DOS disk code had to be converted to use 32-bit sector numbers, a task complicated by the fact that it was written in 16-bit assembly language.

In 1988 the improvement became more generally available through MS-DOS 4.0. The limit on partition size was now dictated by the 8-bit signed count of sectors-per-cluster, which had a maximum power-of-two value of 64. With the usual hard disk sector size of 512 bytes, this gives 32 KB clusters, hence 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 anyway, generated massive internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk utilities didn't work with it.

Long File Names (VFAT, LFNs)

One of the "user experience" goals for the designers of Windows 95 was the ability to use long file names (LFNs), in addition to classic 8.3 names. LFNs were implemented using a work-around 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 VxD device driver.

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. It was a backport; Microsoft's ads for WfW 3.11 said 32-bit File Access was based on "the 32-bit file system from our Chicago project".

In Windows NT, support for long file names on FAT started from version 3.5.

FAT32

In order to overcome the volume size limit of FAT16, while still allowing DOS real-mode code to handle the format without unnecessarily reducing the available conventional memory, Microsoft decided to implement a newer generation of FAT, known as FAT32, with cluster counts held in a 32-bit field, of which 28 bits are currently used.

In theory, this should support a total of approximately 268,435,438 (< 2²⁸) clusters, allowing for drive sizes in the range of 2 terabytes. However, due to limitations in Microsoft's scandisk utility, the FAT is not allowed to grow beyond 4,177,920 (< 2²²) clusters, placing the volume limit at 124.55 gigabytes, unless "scandisk" is not needed [2].

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, support for FAT32 arrived in Windows 2000.

Windows 2000 and Windows XP can read and write to FAT32 filesystems of any size, but the format program on these platforms can only create FAT32 filesystems up to 32GB. Thompson and Thompson (2003) write<ref>Thompson, Robert Bruce and Thompson, Barbara Fritchman; PC Hardware in a Nutshell, 3rd Edition,, O'Reilly, ISBN 059600513X (p. 506: Microsoft "bizarrely" saying the 32GB limitation is by design)</ref> that "Bizarrely, Microsoft states that this behavior is by design." Microsoft's knowledge base article 184006<ref>Limitations of FAT32 File System, Microsoft knowledge base article 184006</ref> indeed confirms the limitation, but gives no rationale or explanation. Peter Norton's opinion<ref>Norton, Peter (2002); Peter Norton's New Inside the PC, Sams Publishing, ISBN 0672322897 (p. 428: "Microsoft has intentionally crippled the FAT32 file system")</ref> is that "Microsoft has intentionally crippled the FAT32 file system."

The maximum possible size for a file on a FAT32 volume is 4GiB minus 1B (2³²-1 bytes). For most users, this has become the most nagging limit of FAT32 as of 2005, since video capture and editing applications can easily exceed this limit, as can the system swap file.

Third party support

The alternative IBM PC operating systems — such as Linux, FreeBSD, and BeOS — have all supported FAT, and most added support for VFAT and FAT32 shortly after the corresponding Windows versions were released. Early Linux distributions also supported a format known as UMSDOS, which was FAT with Unix file attributes (such as long file name and access permissions) stored in a separate file called --linux-.---. UMSDOS fell into disuse after VFAT was released and is not enabled by default in Linux kernels from version 2.5.7 onwards [3]. The Mac OS X operating system also supports the FAT filesystems on volumes other than the boot disk.

FAT and Alternate Data Streams

The FAT filesystem itself is not designed for supporting 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). The second design, while presumably more efficient, prevents any copying or backing-up of those volumes using non-aware tools; manipulating such volumes using non-aware disk utilities (e.g. defragmenters or CHKDSK) will probably lose the information.

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 metadata (Resource Forks, 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).

Windows NT supports the handling of extended attributes in HPFS, NTFS, and FAT. It stores EAs on FAT using exactly the same scheme as OS/2, but does not support an 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 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").

Future

Microsoft has recently secured patents for VFAT and FAT32 (but not the original FAT), which is causing concern that they might later seek royalties from Linux distros and from media vendors that pre-format their products (see FAT Licensing below). Despite two earlier rulings against them, Microsoft prevailed and were awarded the patents.

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, 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 they severely limited what could be done through it by default for security reasons.

FAT is still the normal filesystem 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 is not yet large enough to benefit from FAT32. FAT is used on these drives for reasons of compatibility and size overhead, as well as the fact that file permissions on removable media are likely to be more trouble than they are worth.

The FAT32 formatting support in Windows 2000 and XP is limited to drives of 32 gigabytes, which effectively forces users of modern hard drives either to use NTFS or to format the drive using other tools outside Windows. A workaround to this involves using a version of mkdosfs that has been ported from Linux to Windows.

There is also a free and open source utility available here.

Design

Main disk structures

Master  Boot  Record

File  Allocation Table #1

File  Allocation Table #2

Root  Directory

All Other Data ... The Rest of the Disk

A FAT file system is composed of four different sections.

1. The Reserved sectors, located at the very beginning. The first reserved sector 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 thru an operating system structure called the Drive Parameter Block in DOS and OS/2.
2. The FAT Region. This contains two copies of the File Allocation Table for the sake of redundancy, although the extra copy is rarely used, even by disk repair utilities. These are maps of the partition, indicating how the clusters are allocated.
3. The Root Directory Region. This is a Directory Table that stores information about the files and directories in the root directory. With FAT32 it can be stored anywhere in the partition, however with earlier versions it is always located immediately after the FAT Region.
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 each cluster can be taken only by one file, and so if a 1 KB file resides in a 32 KB cluster, 31 KB are wasted.

Boot Sector

The Boot Sector is of the following format:

Byte Offset	Length (bytes)	Description
0x00	3	Jump instruction (to skip over header on boot)
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 [4] [5]. Common values are IBM  3.3 (with two spaces between the "IBM" and the "3.3") and MSDOS5.0.
0x0b	2	Bytes per sector. The BIOS Parameter Block starts here.
0x0d	1	Sectors per cluster
0x0e	2	Reserved sector count (including boot sector)
0x10	1	Number of file allocation tables
0x11	2	Maximum number of root directory entries
0x13	2	Total sectors (if zero, use 4 byte value at offset 0x20)
0x15	1	Media descriptor 0xF8 Single sided, 80 tracks per side, 9 sectors per track 0xF9 Double sided, 80 tracks per side, 9 sectors per track 0xFA Single sided, 80 tracks per side, 8 sectors per track 0xFB Double sided, 80 tracks per side, 8 sectors per track 0xFC Single sided, 40 tracks per side, 9 sectors per track 0xFD Double sided, 40 tracks per side, 9 sectors per track 0xFE Single sided, 40 tracks per side, 8 sectors per track 0xFF Double sided, 40 tracks per side, 8 sectors per track Same value of media descriptor should be repeated as first byte of each copy of FAT. Certain operating systems (MSX-DOS version 1.0) ignore boot sector parameters altogether and use media descriptor value from the first byte of FAT to determine filesystem parameters.
0x16	2	Sectors per file allocation table (FAT16)
0x18	2	Sectors per track
0x1a	2	Number of heads
0x1c	4	Hidden sectors
0x20	4	Total sectors (if greater than 65535; see offset 0x13)
0x24	4	Sectors per file allocation table (FAT32). The Extended BIOS Parameter Block starts here.
0x24	1	Physical drive number (FAT16)
0x25	1	Current head (FAT16)
0x26	1	Signature (FAT16)
0x27	4	ID (FAT16)
0x2b	11	Volume Label
0x36	8	FAT file system type (e.g. FAT, FAT12, FAT16, FAT32)
0x3e	448	Operating system boot code
0x1FE	2	End of sector marker (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).

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

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 chains 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 address of the next cluster in a chain
• a special end of file (EOF) character that indicates the end of a chain
• a special character to mark a bad cluster
• a special character to mark a reserved cluster
• a zero to note that that cluster is unused

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

FAT12	FAT16	FAT32	Description
0x000	0x0000	0x?0000000	Free Cluster
0x001	0x0001	0x?0000001	Reserved Cluster
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
0xFF7	0xFFF7	0x?FFFFFF7	Bad 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 area 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 bits of this entry are 1. In the second entry the end-of-file 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.[6]

Directory table

A directory table is a special type of file that represents a directory (nowadays commonly 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.

Legal characters for DOS file names include the following:

• Upper case letters A-Z
• Numbers 0-9
• Space (though trailing spaces are considered to be padding and not a part of the file name)
•  ! # $ % & ( ) - @ ^ _ ` { } ~ '
• Values 128-255

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:

Byte Offset	Length	Description
0x00	8	DOS file name (padded with spaces) The first byte can have the following special values: 0x00 Entry is available and no subsequent entry is in use 0x05 Initial character is actually 0xE5 0x2E 'Dot' entry; either '.' or '..' 0xE5 Entry has been previously erased and is not available. File undelete utilities must replace this character with a regular character as part of the undeletion process.
0x08	3	DOS file extension (padded with spaces)
0x0b	1	File Attributes The first byte can have the following special values: Bit Mask Description 0 0x01 Read Only 1 0x02 Hidden 2 0x04 System 3 0x08 Volume Label 4 0x10 Subdirectory 5 0x20 Archive 6 0x40 Device (internal use only, never found on disk) 7 0x80 Unused An attribute value of 0x0F is used to designate a long file name entry.
0x0c	1	Reserved, used by NT (see below)
0x0d	1	Create time, fine resolution: 10ms units, values from 0 to 199.
0x0e	2	Create time. The hour, minute and second are encoded according to the following bitmap: Bits Description 15-11 Hours (0-23) 10-5 Minutes (0-59) 4-0 Seconds/2 (0-29) Note that the seconds is recorded only to a 2 second resolution. Finer resolution for file creation is found at offset 0x0d.
0x10	2	Create date. The year, month and day are encoded according to the following bitmap: Bits Description 15-9 Year (0 = 1980, 127 = 2107) 8-5 Month (1 = January, 12 = December) 4-0 Day (1 - 31)
0x12	2	Last access date; see offset 0x10 for description.
0x14	2	EA-Index (used by OS/2 and NT) in FAT12 and FAT16, High 2 bytes of first cluster number in FAT32
0x16	2	Last modified time; see offset 0x0e for description.
0x18	2	Last modified date; see offset 0x10 for description.
0x1a	2	First cluster in FAT12 and FAT16. Low 2 bytes of first cluster in FAT32.
0x1c	4	File size

Long File Names (LFN) are stored on a FAT file system using a trick - adding phoney entries into the Directory Tables. The entries are marked with a Volume Label attribute which is impossible for a regular file and because of that they are ignored by most old MS-DOS programs. 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.

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 a space (ASCII 0x20) char. 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) ? 0x80 : 0) + (sum >> 1) + *pFcbName++;
	return sum;
}

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 phoney entry can contain up to 13 UTF-16 characters (26 bytes), gaining about 15 bytes in addition to the old 8 + 3 by using fields in the record which contained file size or time stamps (but for security versus disk checking tools the starting cluster field is left unused with a 0 value). See 8.3 for additional explanations.

LFN entries use the following format:

Byte Offset	Length	Description
0x00	1	Sequence Number
0x01	10	Name characters (five UTF-16 characters)
0x0b	1	Attributes (always 0x0F)
0x0c	1	Reserved (always 0x00)
0x0d	1	Checksum of DOS file name
0x0e	12	Name characters (six UTF-16 characters)
0x1a	2	First cluster (always 0x0000)
0x1c	4	Name characters (two UTF-16 characters)

If a filename contains only lowercase letters, or is a combination of a lowercase basename with an uppercase extension, or vice-versa, has no special characters, and fits within the 8.3 limits, a VFAT entry is not created on Windows NT. Instead, undocumented 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. Non-NT Windows versions see all-uppercase filenames if this extension has been used. By default, recent versions of Linux will recognize this extension but won't use it 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:

Byte Offset	Length	System	Description
0x0C	2	RISC OS	File type, 0x000 - 0xFFF
0x0C	1	DOS Plus	User-defined file attributes F1-F4 Bit Mask Description 7 0x80 F1 6 0x40 F2 5 0x20 F3 4 0x10 F4
0x0D	1	DR-DOS	For a deleted file, the original first character of the filename.
0x0E	2	DR-DOS and FlexOS	Encrypted file password
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): Bit Mask Description 0 0x0001 Owner delete requires password 1 0x0002 Owner execute requires password 2 0x0004 Owner write requires password 3 0x0008 Owner read requires password 4 0x0010 Group delete requires password 5 0x0020 Group execute requires password 6 0x0040 Group write requires password 7 0x0080 Group read requires password 8 0x0100 World delete requires password 9 0x0200 World execute requires password 10 0x0400 World write requires password 11 0x0800 World read requires password

FAT licensing

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

On December 3 2003, Microsoft announced 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 filesystem as the basis of its intellectual property claims. All four pertain to long-filename extensions to FAT first seen in Windows 95:

• Template:US patent - 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-compatible 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.
• Template:US patent - Common name space for long and short filenames. Filed for on April 24, 1995. This covers the method of chaining together multiple consecutive 8.3 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 September 14 2004, due to prior disclosure of the claimed techniques in patents Template:US patent and Template:US patent. This decision was later overturned by the Patent Office on January 10, 2006.
• Template:US patent - Common name space for long and short filenames. Filed on September 5, 1996. This is very similar to 5,579,517.
  • The Public Patent Foundation successfully challenged this patent; The USPTO rejected this patent on October 5, 2005, on the grounds that "the six assignees names were incorrect" [7]. This decision was also later overturned by the Patent Office on January 10, 2006.
• Template:US patent - Method and system for providing a common name space for long and short file names in an operating system. Filed on January 28, 1997. This makes claims on the methods used when Windows 95, Windows 98 and Windows Me expose long filenames to their MS-DOS compatibility layer. It does not appear to affect any non-Microsoft FAT implementations.

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

Additionally, in the document "Microsoft Extensible Firmware Initiative FAT 32 File System Specification, FAT: General Overview of On-Disk Format" published by Microsoft (version 1.03, December 6, 2000), Microsoft specifically grants a number of rights, which many readers have interpreted as permitting operating system vendors to implement FAT.

Appeal

As there was widespread call for these patents to be re-examined, the Public Patent Foundation 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 September 30 2004, the USPTO rejected all claims of Template:US patent, based primarily on evidence provided by the Public Patent Foundation. 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 October 5, 2005, 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 Template:US patent invalid on the grounds that the patent had incorrect assignees.

Finally, on January 10, 2006, 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.

Footnotes

• Template:Note Patents apply to technology supporting Long File Names within the file system, but not the core file system itself.

References

<references/>

See also

• Comparison of file systems
• Drive letter assignment
• Software patent
• List of file systems
• Rock Ridge and Joliet — systems for CDs that add long file names similar to what vfat did for fat.

External links

• News article about final patent ruling
• Microsoft's statement on "FAT File System Technology and Patent License"
• Slashdot discussion on Microsoft's claims of FAT-related patents
• Microsoft Extensible Firmware Initiative FAT 32 File System Specification, FAT: General Overview of On-Disk Format
• Understanding FAT32 Filesystems (explained for embedded firmware developers)
• Microsoft's war on GPL dealt patent setback
• A Short History of MS-DOS, by Tim Paterson
• Detailed Explanation of FAT Boot Sector - Microsoft Knowledge Base Article 140418
• At PUBPAT's Request, Patent Office Rejects Microsoft's FAT Patent: All Claims of Reynolds '517 Patent Ruled Invalid
• Volume and file size limits of FAT filesystems
• Overcoming FAT 32 Limitations
• Implementation of OS/2 extended attributes on the FAT file system.da:FAT

de:File Allocation Table es:FAT eu:FAT fa:جدول تخصیص فایل fr:FAT32 he:FAT it:File Allocation Table ja:File Allocation Table ko:FAT32 lt:FAT nl:FAT32 pl:File Allocation Table pt:FAT32 ru:FAT32 sv:FAT32 tr:Dosya Yerleşim Tablosu

zh:FAT