Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
File Allocation Table
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Extensions == <!-- === Flash and ROM FAT extensions === for FAT extensions like FTL === Secured FAT === for single/multiuser security schemes including those by DRI and Linux === Compressed FAT === for compressed and encrypted FAT schemes === Deletion tracking === for MSX-DOS, SAVENAME, DELWATCH, SENTRY, UNDELETE, RECYCLE etc. === Large file support === for files larger than 2/4 GB, FAT+ etc. === Transaction-safe FAT === for TFAT and other transaction safe FAT variants --> === <span id="EA"></span>Extended attributes === [[OS/2]] heavily depends on [[extended attribute]]s (EAs) and stores them in a hidden file called "<code>EA␠DATA.␠SF</code>"<!-- Since the exact spelling is important and most sources list only 10 of the 8+3 available characters in directory entries, recheck the exact 8+3 byte spelling of this filename --> in the [[root directory]] of the [[#FAT12|FAT12]] or [[#FAT16|FAT16]] volume. This file is indexed by two previously reserved bytes in the file's (or directory's) [[FAT directory entry|directory entry]] at offset [[Design of the FAT file system#DIR OFS 14h|<code>0x14</code>]].<ref name="Eager_2000_EA" /> In the [[#FAT32|FAT32]] format, these bytes hold the upper 16 bits of the starting cluster number of the file or directory, hence making it impossible to store [[OS/2 EA]]s on FAT32 using this method. However, the third-party FAT32 [[installable file system]] (IFS) driver FAT32.IFS version 0.70 and higher by Henk Kelder & Netlabs for OS/2, [[eComStation]] and [[ArcaOS]] stores extended attributes in extra files with filenames having the string "<code>␠EA.␠SF</code>" appended to the regular filename of the file to which they belong. The driver also utilizes the byte at offset [[Design of the FAT file system#DIR OFS 0Ch|<code>0x0C</code>]] in directory entries to store a special mark byte indicating the presence of extended attributes to help speed up things.<ref name="Kelder_2003_FAT32IFS0913" /><ref name="Kelder_FAT32IFS074" /> (This extension is critically incompatible with the FAT32+ method to store files larger than 4 GB minus 1 on FAT32 volumes.)<ref name="DRDOS_FAT+_R2" /> Extended attributes are accessible via the [[Workplace Shell]] desktop, through [[REXX]] scripts, and many system [[graphical user interface|GUI]] and [[command line interface|command-line]] utilities (such as [[4OS2]]).<ref name="Eager_2000_Tavi" /> To accommodate its [[OS/2]] subsystem, [[Windows NT]] supports the handling of extended attributes in [[High Performance File System|HPFS]], [[NTFS]], FAT12 and FAT16. It stores EAs on FAT12, FAT16 and HPFS using exactly the same scheme as OS/2, but does not support any other kind of [[Alternate Data Streams|ADS]] as held on NTFS volumes. Trying to copy a file with any ADS other than EAs from an NTFS volume to a FAT or HPFS volume gives a warning message with the names of the ADSs that will be lost. It does not support the FAT32.IFS method to store EAs on FAT32 volumes. [[Windows 2000]] onward acts exactly as Windows NT, except that it ignores EAs when copying to FAT32 without any warning (but shows the warning for other ADSs, like "Macintosh Finder Info" and "Macintosh Resource Fork"). [[Cygwin]] uses "<code>EA␠DATA.␠SF</code>" files as well. === <span id="LFN"></span><span id="VFAT"></span><span id="UVFAT"></span>Long file names === <!-- use LFN anchor for generic FAT long filename solutions and VFAT for Microsoft's VFAT --> One of the [[user experience]] goals for the designers of [[Windows 95]] was the ability to use [[long filename]]s (LFNsβup to 255 [[UTF-16]] [[code unit]]s long),<ref group="nb" name="NB_LFN_UNI"/> in addition to classic [[8.3 filename]]s (SFNs). For [[backward compatibility|backward]] and [[forward compatibility]], LFNs were implemented as an optional extension on top of the existing FAT file system structures using a [[workaround]] in the way directory entries are laid out. This transparent method to store long file names in the existing FAT file systems without altering their data structures is usually known as '''[[VFAT long filename|VFAT]]''' (for "Virtual FAT") after the Windows 95 [[VxD|virtual device driver]].<ref group="nb" name="NB_VFAT_Name" /> Non VFAT-enabled operating systems can still access the files under their short file name alias without restrictions; however, the associated long file names may be lost when files with long filenames are copied under non VFAT-aware operating systems. In Windows NT, support for VFAT long filenames began with version [[Windows NT 3.5|3.5]]. Linux provides a VFAT filesystem driver to work with FAT volumes with VFAT long filenames. For some time, a [[UVFAT]] driver was available to provide combined support for [[#UMSDOS|UMSDOS]]-style permissions with VFAT long filenames. [[OS/2]] added long filename support to FAT using [[FAT extended file attributes|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; therefore, experienced users of both operating systems would have to manually rename the files. [[Human68K]] supported up to [[18.3 filename]]s and ([[Shift JIS]]) [[Kanji]] characters in a proprietary FAT file system variant. In order to support [[Java (programming language)|Java]] applications, the [[FlexOS]]-based [[IBM 4690 OS]] version 2 introduced its own [[virtual file system]] (VFS) architecture to store long filenames in the FAT file system in a backwards-compatible fashion. If enabled, the virtual filenames (VFN) are available under separate logical drive letters, whereas the real filenames (RFN) remain available under the original drive letters.<ref name="IBM_4690_Programming_Guide" /> === <span id="ADS"></span>Forks and alternate data streams === The FAT file system itself is not designed for supporting [[fork (file system)|alternate data streams]] (ADS), but some operating systems that heavily depend on them have devised various methods for handling them on FAT volumes. Such methods either store the additional information in extra files and directories ([[classic Mac OS]] and [[macOS]]), 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 "<code>FINDER.DAT</code>", and [[resource fork]]s (a common Mac OS ADS) in a subdirectory called "<code>RESOURCE.FRK</code>", 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. [[macOS]] stores [[resource fork]]s and metadata (file attributes, other ADS) using [[AppleDouble format]] in a hidden file with a name constructed from the owner filename prefixed with "<code>._</code>", and [[Finder (software)|Finder]] stores some folder and file metadata in a hidden file called "<code>[[.DS_Store]]</code>" (but note that Finder uses <code>.DS_Store</code> even on macOS' native filesystem, [[HFS+]]). === <span id="UMSDOS"></span>UMSDOS permissions and filenames === {{further|FAT filesystem and Linux}} 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 "<code>--linux-.---</code>". UMSDOS fell into disuse after [[#VFAT|VFAT]] was released and it is not enabled by default in [[Linux]] from version 2.5.7 onwards.<ref name="Linux_ChangeLog257" /> For some time, Linux also provided combined support for UMSDOS-style permissions and VFAT long filenames through [[UVFAT]]. === <span id="FAT16+"></span><span id="FAT32+"></span><span id="FAT32B"></span>FAT+ === In 2007 the open '''FAT+''' draft proposed how to store [[Large file support|larger files]] up to 256 GB minus 1 byte, or 274,877,906,943 (2<sup>38</sup> β 1) bytes, on slightly modified and otherwise backward-compatible FAT32 volumes,<ref name="DRDOS_FAT+_R2" /> but imposes a risk that disk tools or FAT32 implementations not aware of this extension may truncate or delete files exceeding the normal FAT32 file size limit. Support for '''FAT32+''' and '''FAT16+''' is limited to some versions of [[DR-DOS]] and not available in mainstream operating systems.<ref>{{cite web |url=http://www.drdosprojects.de/ |title=DR-DOS/OpenDOS Enhancement Project |first=Udo |last=Kuhnt |date=July 21, 2011 |access-date=2015-04-20 |archive-date=2016-07-06 |archive-url=https://web.archive.org/web/20160706205139/http://www.drdosprojects.de/ |url-status=live }}</ref> (This extension is critically incompatible with the <code>/EAS</code> option of the FAT32.IFS method to store [[FAT extended file attributes|OS/2 extended attributes]] on FAT32 volumes.)
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)