Hubbry Logo
Long filenameLong filenameMain
Open search
Long filename
Community hub
Long filename
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Long filename
Long filename
Long filename
View on Wikipedia
from Wikipedia

Long filename (LFN) support is Microsoft's backward-compatible extension of the 8.3 filename (short filename) naming scheme used in MS-DOS. Long filenames can be more descriptive, including longer filename extensions such as .jpeg, .tiff, and .html that are common on other operating systems, rather than specialized shortened names such as .jpg, .tif, or .htm. The standard has been common with File Allocation Table (FAT) filesystems since its first implementation in Windows NT 3.5 of 1994.

To maintain compatibility with older operating systems, Microsoft formulated a method of generating an 8.3 filename from the long filename (for example, Microsoft.txt to MICROS~1.TXT) and associating it with the file.

Further information: Design of the FAT file system § VFAT long file names

Compatibility issues

[edit]

Microsoft implemented support for LFNs in the FAT filesystem by using hidden directory entries, of the volume label type, to store the longer names; this scheme is known as VFAT, and was chosen for compatibility, as volume labels are generally ignored by programs and operating system (OS) components. Programs running on older OSs could still access the files' short names, while newer, LFN-aware OSs and programs could use the longer ones.

When LFN support was first introduced into a DOS-based operating system in the form of Windows 95, it caused some problems for older programs. For example, a DOS program performing sector-level directory operations while Windows was in DOS mode could destroy long filename information so, by default, sector-level access to hard disks was disallowed in this mode.

Upon booting into plain DOS, the long filenames are not visible unless a VFAT LFN driver is installed. Microsoft did not add LFN support to many of its older programs, including File Manager, the Windows 3.1x (Windows for Workgroups) file manager that was made obsolete by the new operating system shell, Windows Explorer. Windows NT supported LFNs on NTFS file systems starting with the release of NT 3.1, and all of its utilities, including File Manager, were updated to support LFNs. NT 3.5 added FAT LFN support in preparation for Windows 95. However, the Windows 95 version of File Manager came from Windows for Workgroups 3.11.

OS/2 stores LFNs for FAT filesystems in .LONGNAME extended attributes that are incompatible with Microsoft's implementation and only visible to tools supporting OS/2's standard. Many APIs providing access to files by pathname cannot see the new, longer names without a supporting driver.

Limits

[edit]

Because the FAT LFN implementation is layered atop an older, more limited naming system, there are inevitable complications, such as if an attempt is made to create too many files with the same first six letters.[1] Also, one is more likely to encounter issues creating files or folders in the root directory, since FAT12 and FAT16 only allocate space for 512 root directory entries on hard disks. Since long filenames use more than one directory entry, this problem may occur with fewer than 512 files or folders in the root directory.[2] There is space only for 24 long filenames of maximum length (512/(1+20)). This problem does not exist for FAT32 volumes.

The long filename system allows a maximum length of 255 UCS-2 characters[3][4] including spaces and non-alphanumeric characters (excluding the following characters, which have special meaning within the COMMAND.COM command interpreter or the operating system kernel: \ / : * ? " < > |). This is achieved by chaining up to 20 directory entries of 13 2-byte Unicode characters each.[4] The maximum length of a pathname is 256 characters, which includes all parent directories and the filename. 255-character mixed-case long filename is possible only for files, or folders with no sub-folders, at the root folder of any drive.

While long filename support allows for longer file and directory names, under DOS-based systems, the absolute file path constructed from the associated short file and directory name equivalents is still represented in an internal data structure called the Current Directory Structure (CDS),[5][6][7][8] which imposes a limit of 66 characters on the (short) path name and thereby indirectly limits also the path depth to a maximum of 33 levels (counting in the root directory and assuming only single-letter names). (This design limitation was not present in older versions of DR DOS (prior to DR DOS 6.0 November 1991 updates) which still utilized a relative path representation internally,[7][8][9] however, due to their internal differences these versions are not compatible with existing LFN add-on drivers.) Non-DOS-based operating systems without a CDS are not restricted to this path depth limitation.

VFAT LFN drivers

[edit]

The following is a list of drivers that can be used to provide support for VFAT long file names as used in Windows 95. Although drivers such as DOSLFN can be loaded in almost any versions of DOS, it works best on DOS versions that have support for LFN themselves, such as MS-DOS 7.10 or DR-DOS 7.02, so that DOS commands such as DIR would show long file names as well.

OS Driver name Provider
any plain DOS DOSLFN, LFNDOS third-party
DR-DOS LONGNAME included
RxDOS built-in included
OS/2 VFAT-OS2.IFS third-party
Windows NT 4.0 NTLFN third-party

Driver-less real mode DOS LFN commands

[edit]

Some small real mode DOS programs have also been written over the years, although many have been lost over time. One notable collection of programs that still exists is LFN Tools, which is open source and comprises seven useful LFN commands written in C++ and assembly language, with documentation included in English and German, and is available at LFNTOOLS on Sourceforge.net.

Other implementations

[edit]

Before LFN support was implemented into the FAT family of file systems, various file managers provided their own methods to attach and maintain longer file descriptions. Among the first to do so are the alternative command line processors 4DOS and NDOS with their internal DESCRIBE command and corresponding DESCRIPT.ION files. The latter are optional hidden files located in each directory storing a line-based list of file names located in the directory together with their textual description and optional metadata entries—for example, extended attributes and configuration data for other programs.[10] The descriptions can be up to 511 characters long and are displayed along the file names in much the same way as long file names are listed alongside their short filename aliases in DIR listings. If an entry exists for a file, it will be copied and moved with the file for as long as these command line processors are used to perform the operation.[9] This scheme is still maintained by successors such as 4OS2, 4NT / Take Command. It was adopted also by various other programs like Volkov Commander (VC), DOS Navigator (DN), Open DOS Navigator (ODN), Necromancer's DOS Navigator (NDN), Windows Commander, Total Commander, Double Commander, 7-Zip, XnView, ACDSee, Newsbin Pro, V, FreeDOS[11] and some CUI_LIB[12]-based applications.

Human68K, the operating system of the X68000 computers since 1986, is based on an extended FAT file system. It allows up to 18.3 characters in a filename (instead of the 8.3 in FAT) and allows also upper and lower case characters (as well as Kanji in Shift JIS code) that are all treated as distinctive. If restricted to the use of 8.3-format filenames with upper case characters only, the Human68K floppies are fully compatible with the Japanese 1232 KiB standard FAT floppy format (77 cylinders, 2 heads, 8 sectors, 1024 bytes/sector). This format is used by the NEC PC-9800, Fujitsu FMR and FM Towns series computers.[citation needed]

Novell NetWare versions 3.x and 4.x volumes can also support Microsoft-compatible long filenames, by loading an additional NetWare Loadable Module (NLM).[13]

In order to support Java applications without implementing a VFAT-compatible scheme, 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.[14]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Long filename

View on Grokipedia
from Grokipedia
Long filenames (LFNs), also known as long file name support, are a file naming extension in Microsoft Windows operating systems that allow file and directory names to exceed the traditional 8.3 character limit (eight characters for the base name plus a three-character extension) originally imposed by and early FAT file systems. Introduced with in 1995, this feature uses the VFAT (Virtual File Allocation Table) driver to enable descriptive, user-friendly names on FAT file systems while maintaining backward compatibility with legacy applications through automatically generated 8.3 short filename aliases. LFNs are implemented by storing additional directory entries in the directory structure, where each LFN entry holds up to 13 characters (26 bytes), allowing a complete of up to 255 characters per component when multiple entries are chained together. This system supports international characters via , replacing the ASCII limitations of short filenames, and is available on file systems through the VFAT extension and natively on file systems in Windows. For compatibility, Windows generates a shortened 8.3 alias (e.g., using tildes like "LONGFI~1.TXT") for each LFN unless explicitly disabled via registry settings, ensuring older software can still access files. Over time, LFN support has evolved to address path length limitations; prior to Windows 10 version 1607, the overall file path was capped at MAX_PATH (260 characters, including the null terminator), but individual filename components could reach 255 characters. Starting with Windows 10 version 1607 and continuing in , extended-length paths up to approximately 32,767 characters are possible by enabling the LongPathsEnabled registry key and using the "\?" prefix, though this requires application manifests to declare long path awareness for full functionality. Despite these advances, certain restrictions persist, such as the inability to use reserved characters (e.g., <, >, :, ", /, , |, ?, *) in names and the need for around paths containing spaces in command-line operations.

History and Development

Origins in DOS Limitations

The 8.3 filename convention in and the early restricted file names to a maximum of eight alphanumeric characters for the base name, followed by a period and up to three characters for the extension, with all characters converted to uppercase and limited to the ASCII set excluding certain reserved symbols like . " / \ [ ] : ; | = ,. This format was a direct holdover from , the operating system that emulated for compatibility, as the fixed 11-character structure (8+3) fit efficiently within 's 32-byte directory entry size, allocating 8 bytes for the name, 3 for the extension, and space for metadata like timestamps and attributes. Introduced with 1.0 in August 1981, the file system provided basic file allocation without any support for longer or more descriptive names, reflecting its origins in Microsoft's 1977 Stand-alone Disk and adaptations for IBM's PC hardware. Over the subsequent versions, from 2.0's addition of subdirectory support in 1983 to 6.22 released in May 1994, the core filename limitations persisted unchanged, as the system evolved primarily to accommodate larger hard drives and improved compression without altering the . These constraints arose from deliberate design choices emphasizing simplicity and reliability on resource-limited early hardware, such as 160 KB floppy disks, where fixed-length fields in 32-byte directory entries enabled quick parsing without variable-length processing or complex string handling. Compatibility with applications and avoidance of overhead in low-memory environments further reinforced the 8.3 limit, preventing issues like name collisions on media with minimal storage. For instance, a file named "PROGRAM.EXE" complied fully, but a descriptive name like "My Document File.txt" would fail due to exceeding the character limit, spaces, and multiple periods. This rigidity motivated later extensions like VFAT to enable longer names while preserving .

Introduction with VFAT in Windows 95

Windows 95, released on August 24, 1995, marked the debut of long filename support through the VFAT file system extension, enabling users to employ descriptive filenames up to 255 characters in length using Unicode characters. This capability addressed the limitations of prior DOS systems, where filenames were confined to an 8.3 format of eight characters for the base name and three for the extension. VFAT extended the existing FAT12 and FAT16 file systems without requiring a complete overhaul, allowing seamless integration into the graphical interface of Windows 95 while preserving access to legacy applications. Microsoft's development of VFAT stemmed from the need to bridge the gap between DOS-era constraints and the more intuitive file management required for modern consumer operating systems. The extension was crafted in collaboration with original equipment manufacturers (OEMs) to facilitate broad deployment on pre-installed PCs, ensuring that VFAT could handle the growing complexity of file naming in a GUI environment. By storing long names in hidden directory entries marked with specific attributes, VFAT maintained , automatically generating short 8.3 aliases for files with extended names. Among the key innovations, VFAT permitted the use of spaces within filenames, preserved the case of lowercase letters, and allowed multiple extensions separated by periods, enhancing for everyday tasks like document organization. These features were initially rolled out in the original release and further refined in subsequent updates, such as OEM Service Release 2 in 1996, which expanded capabilities overall. Adoption extended to enterprise environments with integration into , released in September 1994, where VFAT provided FAT-based long filename support to align with upcoming compatibility needs.

Technical Implementation

LFN Directory Entry Structure

In the VFAT file system, long filenames (LFNs) are stored using one or more specialized 32-byte directory entries that precede the corresponding 8.3 short filename (SFN) entry in the directory cluster. Each LFN entry accommodates up to 13 characters, allowing a maximum length of 255 characters across up to 20 consecutive entries. These entries are identified by a specific attribute value and include a for verifying integrity against the associated SFN. The ordinal field at offset 0 (1 byte) serves as a sequence number, with values ranging from 0x01 to 0x14 for non-terminal entries and 0x41 to 0x54 for the terminal entry (where bit 6 is set to indicate the end of the LFN chain). The first entry in the chain (lowest ordinal) corresponds to the beginning of the filename, while the terminal entry immediately precedes the SFN entry in the directory order, with subsequent entries appearing in reverse numerical order upward from there. Unused directory slots are filled with 0xFF to distinguish them from valid entries. The character data is stored in UCS-2 (a precursor to UTF-16) little-endian format, divided into three segments: 5 characters (10 bytes) at offsets 1-10, 6 characters (12 bytes) at offsets 14-25, and 2 characters (4 bytes) at offsets 28-31, for a total of 13 characters per entry. The attribute byte at offset 11 is set to 0x0F (combining read-only, hidden, system, and volume label flags) to mark the entry as an LFN and hide it from legacy DOS applications. A 1-byte checksum at offset 13 ensures the LFN matches its SFN, computed from the uppercase ASCII characters of the SFN (including trailing spaces). The type byte at offset 12 and low-word cluster field at offsets 26-27 are reserved and set to 0. For deleted LFNs, the ordinal field is modified to 0xE5, mirroring the deletion marker in standard FAT entries. The following table outlines the complete LFN directory entry layout:
Offset (bytes)Size (bytes)Field NameDescription
01LDIR_OrdSequence number (1-20; bit 6 set for terminal entry).
1-1010LDIR_Name1First 5 characters (UCS-2LE).
111LDIR_AttrAttributes (always 0x0F).
121LDIR_TypeEntry type (always 0).
131LDIR_Chksum of the corresponding SFN.
14-2512LDIR_Name2Next 6 characters (UCS-2LE).
26-272LDIR_FstClusLOFirst cluster low (always 0).
28-314LDIR_Name3Last 2 characters (UCS-2LE).
This structure integrates seamlessly with the existing 32-byte FAT directory entry format, reserving no additional space beyond the chained LFN entries. When the filename exceeds 13 characters, additional entries are allocated contiguously before the SFN, with the total chain length determined by the filename size (e.g., a 20-character name requires two entries). The short filename generation process complements this by deriving an 8.3 alias stored in the trailing standard entry.

Short Filename Generation Algorithm

The short filename generation algorithm in VFAT ensures by deriving a deterministic 8.3-format alias (up to 8 characters for the base name and 3 for the extension, separated by a period) from any long filename, which can exceed these limits and include characters. This process operates on the long filename provided via the operating system's , converting it into an uppercase, ASCII-only short form while preserving the original long name in separate directory entries. The algorithm prioritizes simplicity and uniqueness within the directory, scanning existing short filenames case-insensitively to avoid collisions. The process begins with preprocessing the long filename: all spaces are removed, trailing periods and dots are stripped (retaining only the last meaningful period if present to delineate the extension), and invalid characters for 8.3 format—such as * ? " < > | / \ : + , ; = [ ]—are replaced with underscores (_). The filename is then folded to uppercase. If the resulting name already fits within 8.3 constraints (base ≤8 characters, extension ≤3) and contains no invalid elements, it is used directly as the short filename, padded with spaces if necessary. Otherwise, for longer names, the base is truncated to the first 6 valid characters (skipping any remaining invalid or removed elements), and the extension (if present) to the first 3 characters; a followed by a sequence number (~1) is appended to the base to form the initial . For names without an extension, the entire truncated portion plus 1 serves as the 8-character base. This yields a like "ABCDEF1.GHI" from a longer input. Conflict resolution ensures uniqueness by comparing the candidate short filename (case-insensitively) against all existing short filenames in the directory. If a match is found, the sequence number after the is incremented (e.g., ~2, ~3), and the base is re-truncated if the appended number exceeds available space (e.g., for 10, only the first 5 characters are used, resulting in "ABCDE10.GHI"). This iteration continues until a unique short filename is found or the directory is full, in which case the operation fails. Special cases handle edge conditions, such as long filenames with characters (above 0x7F), which may trigger an immediate ~n suffix to avoid mapping ambiguities in OEM code pages, and filenames ending in spaces or dots, which are normalized by removal. The resulting short filename is always stored in the standard 8.3 directory entry, linked to the long filename via a for validation. For example, the long filename "My Long File Name.txt" is processed by removing spaces to "MyLongFileName.txt", uppercased to "MYLONGFILENAME.TXT", truncated to base "MYLONG" (6 characters) plus "1" for "MYLONG1", and extension "TXT", yielding "MYLONG1.TXT". If this conflicts with an existing file, it becomes "MYLONG2.TXT", and so on. Similarly, "ReadMe.First Draft.doc" removes spaces and extra elements to "READMEFIRSTDRAFT.DOC", truncating to "README~1.DOC". This algorithm maintains a unified where long and short names coexist transparently, allowing legacy 8.3-only applications to access files without modification.

Compatibility and Limitations

Backward Compatibility with 8.3 Filenames

VFAT ensures with legacy 8.3 filenames by generating a short filename (SFN) alias for every long filename (LFN), allowing older applications to access files without modification. The SFN is derived from the LFN through and the addition of numeric tails (e.g., "~1" for uniqueness), stored in a standard directory entry that links to the LFN entries via a . This dual-naming approach enables applications to open files using the SFN, with the operating system transparently translating it to the full LFN during access. In mixed environments combining DOS and Windows applications, legacy DOS programs interact solely with SFNs, as real-mode MS-DOS lacks native LFN support and relies on 8.3 conventions. Windows applications, however, utilize the full LFNs, with the Installable File System Manager (IFSMgr) routing requests across modes (V86 for DOS, protected mode for Win32) to maintain seamless interoperability. Renaming a file via its SFN updates the associated LFN without data loss, preserving the file's integrity and the checksum linkage between entries. For pure DOS compatibility, Windows 95 supports extensions like Interrupt 21h functions 71A0h–71Aah only within its environment, not in standalone real-mode DOS, allowing selective disabling of LFN processing to avoid conflicts with legacy software. Early Windows 95 releases exhibited bugs impacting SFN-LFN interactions, such as failures in short-to-file control block (FCB) conversions that mishandled wildcard translations (e.g., "*" not properly converted to "?"), leading to meta-matching errors and reduced visibility of LFNs in certain searches. These issues were mitigated in subsequent updates, enhancing overall stability.

Length and Character Restrictions

In the VFAT file system, long filenames are limited to a maximum of 255 characters per component, excluding the path separator and null terminator. The overall path length, including all components and the null terminator, is restricted to 260 characters under the Windows API's MAX_PATH constant, though extended paths up to 32,767 characters are possible with specific prefixes in modern implementations. This per-component limit ensures compatibility while allowing significantly longer names than the legacy 8.3 format. VFAT supports Unicode characters encoded in UTF-16 (initially UCS-2) for long filenames, enabling international character sets beyond basic ASCII. This capability was introduced with VFAT in and enhanced in the OSR2 release, which added FAT32 support while maintaining LFN encoding. Allowed characters include printable code points, such as letters, digits, spaces, and symbols from the current , but exclude control characters (ASCII 0-31) and the null terminator. Certain elements are prohibited to prevent conflicts with system devices and commands. Invalid characters include the path separator \, colon :, asterisk *, question mark ?, double quote ", less-than <, greater-than >, and vertical bar |. Reserved names, such as CON, PRN, AUX, NUL, COM1 through COM9, and LPT1 through LPT9, cannot be used as filenames or directory names, regardless of case or extension. Additionally, trailing spaces and periods are automatically trimmed by the Windows shell, although the underlying file system may store them if created via API calls. Unicode normalization is not enforced in VFAT long filenames, meaning equivalent characters in different normalization forms (e.g., composed vs. decomposed) may coexist as distinct names. This behavior persisted through early Windows versions and was not standardized until later file systems like introduced optional normalization in and beyond.

Drivers and Support

VFAT LFN Drivers for Windows

In and 98, the VFAT LFN functionality relies on a set of core drivers that operate in to virtualize access to long filenames on volumes. The Manager (VMM.VXD) serves as the foundational component, handling , paging, and transitions between ring-0 and ring-3 modes while providing services essential for LFN operations, such as page attachment for shared DLLs and registration of Win32 services. Complementing this, IFSMgr.sys acts as the Manager, routing requests to appropriate drivers, managing resources for multiple file systems, and offering ring-0 file I/O services like IFSMgr_Ring0_FileIO for efficient LFN handling. The primary VFAT driver, VFAT.386, implements the virtual logic, enabling LFN support through additional long directory entries (up to 255 characters per ) and managing mounting via FS_MountVolume, disk layouts, and local storage for floppies and fixed disks. These drivers are loaded during system initialization via entries in , with VFAT.386 specified as a static in the Device Init phase, registered through IFSMgcRegisterMount, and configured via the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD. IFSMgr.sys initializes at order A0010000h, hooking legacy interrupts (e.g., Int 21h, 25h, 26h) to support LFN APIs, while VMM.VXD loads subsequently at IniOrder 0xa0010100 to oversee the layer. This setup allows seamless LFN access in both Win32 and DOS environments, with VFAT.386 using VCACHE for 4096-byte page caching and a block cache to optimize directory reads involving multiple LFN entries. Specific LFN APIs, such as FindFirstFile, are handled through VWIN32's mapping to Int 21h functions (e.g., 716Ch for extended opens, 71xxh series with the LFN flag in ECX bit 30), enabling case-preserved Unicode filenames; additionally, flags like FILE_FLAG_POSIX_SEMANTICS in related calls (e.g., CreateFile) enforce rules for case-sensitive matching on VFAT volumes. The evolution of VFAT LFN drivers in later Windows versions shifted toward native, kernel-mode integration without reliance on DOS subsystems. Windows NT 4.0 introduced built-in VFAT support via the fastfat.sys kernel-mode driver, providing 255-character LFN compatibility on volumes ( and ), with support for partitions up to 4 GB, while eliminating the DOS dependency present in Windows 95/98, thus improving stability for enterprise environments. This driver handles LFN through Unicode storage and backward-compatible 8.3 aliases. Native support, including LFN compatibility, was added in and later versions without third-party extensions. In and subsequent versions, fastfat.sys evolved further as a fully kernel-mode component within the I/O Manager framework, enhancing performance through integrated caching mechanisms that mitigate the overhead of multiple directory entries required for LFNs—typically 1-20 extra 32-byte entries per long filename, which can increase directory scan times by up to 20 times compared to short filenames in dense directories. Later iterations incorporated advanced caching, such as read-ahead buffers and lazy writes, to reduce this LFN-induced overhead during file enumeration and access.

Third-Party and DOS-Specific Drivers

Third-party drivers for long filename (LFN) support emerged to extend functionality beyond Microsoft's official VFAT implementations, particularly in pure DOS environments lacking native integration. These drivers, often implemented as terminate-and-stay-resident (TSR) programs, provide the LFN (Interrupt 21h, AH=71h) to enable applications to handle filenames up to 255 characters on s. Installation typically involves loading the driver via , such as DOSLFN, to hook into DOS's file system calls without requiring Windows. One prominent example is DOSLFN, a TSR driver developed initially by Henrik Haftmann in 2001 and later maintained by Jason Hood, offering full LFN API emulation for real-mode DOS versions from 4.0 onward on 386+ processors. It supports operations like directory creation (71h/39h), file finding (71h/4Eh), and renaming (71h/56h), allowing LFN-aware applications such as to access extended names while maintaining backward compatibility with 8.3 short filenames. Early versions focused on FAT12/16/32 passthrough but lacked full handling, limiting international character support until later updates. In the ecosystem, LFN extensions were integrated into the kernel through community projects starting in 2001, enabling native support for long filenames alongside FAT32 without additional TSRs in versions like kernel 2043 and later. This kernel-level implementation updates metadata handling for LFN requirements, such as modified dates, and is compiled with assembly and for broad compatibility in open-source DOS derivatives. Adoption persisted in legacy and embedded systems pre-2000, where resource constraints favored lightweight TSRs over full OS upgrades, though limitations like incomplete persisted in initial third-party releases. Drivers for alternative file systems, such as HPFS and NTFS, provided LFN passthrough in DOS by emulating VFAT-like access. For instance, HPFSDOS and HPFSA enable read-only mounting of HPFS partitions, preserving long filenames created by OS/2 while exposing them via the LFN API. Similarly, NTFS4DOS offers read/write access to NTFS volumes with LFN support in its professional edition, allowing DOS applications to interact with Windows NT/2000 files without conversion to 8.3 format. Microsoft's MS-DOS 7.0, bundled with early Windows 95, included partial LFN awareness via VFAT without extra drivers, but full real-mode functionality required these third-party extensions for standalone DOS use. For networked environments, incorporated LFN support through server-side modules like LONG.NAM, loaded on 4.11 volumes to enable DOS clients to access extended filenames via the filename format, bridging DOS limitations in multi-OS setups. These drivers were particularly vital in pre-2000 legacy hardware and embedded applications, where they facilitated without migrating to Windows-dependent systems.

Usage in DOS Environments

Driver-less Real Mode LFN Commands

In the context of , the real-mode from 7.0 includes internal hooks that enable limited long filename (LFN) support for built-in commands when running in a DOS session on VFAT volumes, without requiring the explicit loading of additional drivers such as VFAT.386 in that session, as the underlying Windows environment provides the necessary LFN API extensions via interrupt 21h function AH=71h. Specific commands like DIR with the /X option display both the LFN and the corresponding short filename (SFN), while REN and can operate on LFNs directly if the volume is accessible as the boot partition. This functionality relies on the presence of VFAT-formatted media and fails on non-VFAT volumes or non-boot partitions, as the support is tied to the system's primary configuration. Additionally, operations remain confined to , lacking multitasking or protected-mode features. MS-DOS 7.10, included in OSR 2 and later, continued this LFN support and added FAT32 file system compatibility. For extended functionality beyond these built-in commands, third-party TSRs like LFNDOS could be employed in pure DOS setups.

Limitations in Pure DOS Setups

In pure MS-DOS 6.22 setups, long filenames (LFNs) are entirely ignored during the boot process, with the operating system recognizing only the corresponding short filenames (SFNs) in the 8.3 format. This leads to issues such as incorrect volume label reporting in directory listings, where MS-DOS 6.22 misinterprets LFN directory entries—marked with Read-Only, Hidden, , and Volume Label attributes—as the actual volume label, rendering it unchangeable and causing display anomalies like garbage characters in place of LFN data. Moreover, disk management operations pose significant risks, as tools like may report errors such as "Volume label does not match" when attempting to remove partitions containing LFNs, while the command fails with "Cannot make directory entry" during volume label changes. These incompatibilities can result in incomplete file deletions or orphaned LFN entries if SFN-based operations are performed without LFN awareness, potentially leading to directory inconsistencies or over time, as non-aware DOS utilities may overwrite or fragment LFN structures without preserving them. At the command line, early DOS versions like 6.22 provide no native mechanisms for creating, renaming, or fully accessing LFNs, confining all file operations to the restrictive 8.3 SFN format and rendering long descriptive names inaccessible or invisible. Users often resort to third-party shells such as 4DOS, which extends command-line functionality to handle LFNs when an appropriate driver is loaded, though this requires additional setup beyond standard DOS capabilities. Hardware constraints further exacerbate these limitations, as LFNs depend on VFAT-formatted volumes, which pure DOS 6.22 cannot reliably access or create on floppy disks due to the inherent FAT12 structure and limited sector space for multiple LFN entries per file. and operating on large VFAT partitions also demands a VFAT-aware or supporting extended functions to handle drives exceeding 8 GB, as standard 6.22 lacks native LBA support and fails on non-extended FAT setups, often resulting in inaccessible or unrecognized volumes. Around the Y2K transition, third-party patches and drivers, such as updated versions of DOSLFN, emerged to retrofit LFN compatibility into legacy DOS environments, addressing both date-handling issues and filename extensions. A key milestone came with 1.3 in 2022, which integrated native LFN support directly into its kernel, replacement, and core utilities, enabling seamless creation and manipulation of long filenames without external drivers in this open-source DOS variant. As of 2025, no further major updates to this LFN feature have been introduced. While driver-less real mode LFN commands provide limited visibility into existing long names on VFAT volumes, they fall short in pure DOS setups by lacking creation or editing capabilities, underscoring the overall incompleteness of support without supplemental software.

Other Implementations

Support in Non-Windows Operating Systems

In , the VFAT filesystem module, which provides full read and write support for long filenames (LFNs) on FAT volumes, has been integrated into the kernel since the 2.0 series released in 1996. This module enables seamless handling of extended filenames up to 255 characters, including support through mount options such as utf8, which interprets filenames in encoding to preserve international characters. Without proper options like iocharset or utf8, the driver may mangle or replace invalid characters to ensure compatibility with the underlying structure. macOS natively uses the Hierarchical File System Plus (HFS+), which supports long filenames exceeding 255 characters, but provides VFAT compatibility through built-in drivers for reading and writing to volumes with LFN support. This allows macOS to access Windows-formatted drives while preserving extended names, though overall path lengths in macOS are limited to approximately 1024 characters. Other operating systems have implemented varying degrees of LFN support on VFAT. ReactOS, an open-source project aiming for binary compatibility with Windows, mirrors the VFAT driver from Windows NT, providing native read/write access to long and Unicode filenames on FAT volumes. In embedded real-time operating systems like QNX Neutrino RTOS, the fs-dos.so module enables full LFN support on FAT12/16/32 volumes, creating long filenames for entries exceeding the 8.3 format or using mixed case, with a maximum length of 255 characters per the VFAT specification. FreeBSD provides VFAT support via its msdosfs kernel module, allowing read/write access to LFNs since version 5.0 in 2003, with similar Unicode handling through mount options. Android, based on Linux, supports VFAT on external storage like SD cards through the kernel's vfat module, preserving LFNs up to 255 characters with UTF-8 encoding. Unix-like systems, including variants, typically handle invalid characters (such as colons or question marks disallowed in VFAT) by stripping or replacing them during file operations on mounted FAT volumes, often using the ? character as a substitute to avoid errors. Cross-platform tools like preserve LFNs when sharing VFAT volumes over networks, mapping extended names via the SMB protocol to ensure fidelity between Windows and Unix clients without truncation.

Evolution in Modern File Systems

The evolution of long filename support in modern file systems builds upon the foundational concepts introduced by VFAT in the , which extended the legacy 8.3 format through supplementary directory entries while maintaining . Subsequent file systems shifted toward native integration of extended names, eliminating the need for such workarounds and enhancing Unicode compatibility for global character representation. This progression addressed limitations in storage efficiency, , and path length, prioritizing seamless handling of descriptive filenames in contemporary environments. NTFS, introduced by in 1993 with , marked a significant advancement by natively supporting (UTF-16) filenames up to 255 characters per component and full paths extending to approximately 32,767 characters via extended-length path APIs. Unlike VFAT, NTFS does not require short 8.3 names, though it optionally generates them for legacy compatibility, a feature that can be disabled to reduce overhead and improve performance on volumes with many files. This design removed the fragmentation caused by VFAT's multiple LFN entries, storing names directly in the master file table (MFT) for better efficiency, while providing robust handling without mandatory normalization, allowing applications to manage equivalence as needed. Microsoft's exFAT, released in 2006 for flash-based storage like USB drives and SD cards, further streamlined long filename support by natively accommodating up to 255 UTF-16 characters per name without any 8.3 short name legacy or supplementary entries. This eliminated VFAT's directory overhead entirely, using a simpler allocation table structure optimized for removable media, where filenames are stored in dedicated directory entries encoded in Unicode to support international characters directly. exFAT's design prioritized portability and efficiency for non-PC devices, avoiding the compatibility bloat of prior FAT variants while enabling larger file sizes and clusters. In open-source ecosystems, Linux's , introduced in 2008 as an of , supports filenames up to 255 bytes in encoding, aligning with the standard for systems and providing native multilingual character handling without VFAT-style extensions. This integration allows for efficient storage of international text, with paths limited practically by kernel buffers (up to 4,096 characters) rather than rigid constraints, reducing the administrative burden of legacy short names. Similarly, Apple's APFS, launched in 2017 with , employs for filenames limited to 255 bytes and supports longer paths through its container-based architecture, emphasizing normalization-resistant storage to preserve application-intended forms while advancing beyond HFS+ limitations in snapshot and features. These systems collectively demonstrate a trend toward overhead-free, Unicode-native long filenames, enhancing usability across diverse platforms.

References

  1. https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
  2. https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
  3. https://learn.microsoft.com/en-us/troubleshoot/windows-client/backup-and-storage/fat-hpfs-and-ntfs-file-systems
  4. https://devblogs.microsoft.com/oldnewthing/20090610-00/?p=17953
  5. https://retrocomputing.stackexchange.com/questions/23917/origin-of-the-8-3-file-names-scheme
  6. https://www.os2museum.com/wp/dos/dos-beginnings/
  7. https://winworldpc.com/product/ms-dos/622
  8. https://elm-chan.org/docs/fat_e.html
  9. https://www.tomshardware.com/software/windows/microsofts-windows-95-release-was-30-years-ago-today-the-first-time-software-was-a-pop-culture-smash
  10. https://devblogs.microsoft.com/oldnewthing/20110826-00/?p=9793
  11. https://euclid.nmu.edu/~rappleto/Classes/CS426/Notes/FileSystems/vfat-file-system.html
  12. https://bitsavers.trailing-edge.com/pdf/microsoft/windows_95/Mitchell_-_Inside_the_Windows_95_File_System_1997.pdf
  13. https://betawiki.net/wiki/Windows_95
  14. https://techterms.com/definition/lfn
  15. https://teslabs.com/openplayer/docs/docs/specs/lfn_specs.pdf
  16. https://patents.google.com/patent/US5758352A/en
  17. https://learn.microsoft.com/en-us/windows/win32/fileio/filesystem-functionality-comparison
  18. https://superuser.com/questions/999232/unicode-filenames-in-windows-vs-mac-os-x
  19. https://learn.microsoft.com/en-us/windows/win32/intl/using-unicode-normalization-to-represent-strings
  20. https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea
  21. https://learn.microsoft.com/en-us/windows/win32/fileio/file-system-overview
  22. https://github.com/adoxa/doslfn
  23. https://www-user.tu-chemnitz.de/~heha/hs/dos/doslfn/
  24. https://sta.c64.org/lfnemu.html
  25. https://sourceforge.net/projects/fdlfn/
  26. https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/kernel.html
  27. https://tldp.org/HOWTO/Filesystems-HOWTO-4.html
  28. https://smallvoid.com/article/dos-mount-ntfs.html
  29. https://support.novell.com/techcenter/articles/ana19961102.html
  30. https://tldp.org/HOWTO/Filesystems-HOWTO-3.html
  31. https://www.cn-dos.net/msdos71/whatsnew.htm
  32. http://jeffpar.github.io/kbarchive/kb/118/Q118493/
  33. https://www.vogons.org/viewtopic.php?t=91136
  34. https://msfn.org/board/topic/174604-overcoming-the-ms-dos-8025-mb-limitation/
  35. https://www.dosdays.co.uk/topics/dos_8_3.php
  36. https://www.freedos.org/
  37. https://www.kernel.org/doc/Documentation/filesystems/vfat.txt
  38. https://support.apple.com/guide/disk-utility/file-system-formats-dsku19ed921c/mac
  39. https://stackoverflow.com/questions/7140575/macos-what-is-the-max-path-length
  40. https://reactos.org/wiki/File_Systems_FAQ
  41. https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.utilities/topic/f/fs-dos.so.html
  42. https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.user_guide/topic/limits_FAT.html
  43. https://docs.freebsd.org/en/books/handbook/filesystems/
  44. https://source.android.com/docs/core/storage
  45. https://unix.stackexchange.com/questions/299667/how-to-deal-with-characters-like-or-that-make-invalid-filenames
  46. https://www.osnews.com/story/9681/the-vfat-file-system-and-linux/
  47. https://learn.microsoft.com/en-us/windows-server/storage/file-server/ntfs-overview
  48. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-behavior
  49. https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification
  50. https://www.pcmag.com/encyclopedia/term/exfat
  51. https://www.kernel.org/doc/html/latest/filesystems/ext4/directory.html
  52. https://lwn.net/Articles/784124/
  53. https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf
  54. https://eclecticlight.co/2022/04/01/a-brief-history-of-apfs-in-honour-of-its-fifth-birthday/
Add your contribution
Related Hubs
User Avatar
No comments yet.