How Windows 95 Handled Non-8.3 File Renaming

When users renamed files in Windows 95 using spaces, lowercase letters, multiple periods, or lengths exceeding the traditional MS-DOS limitations, the operating system utilized the Virtual File Allocation Table (VFAT) subsystem to bridge the gap between modern naming and legacy compatibility. Instead of rejecting names that violated the classic 8.3 format (eight characters for the name, three for the extension), Windows 95 assigned every modified file a dual identity: a human-readable Long File Name (LFN) and a mathematically generated 8.3 Short File Name (SFN) alias. This process ensured full backward compatibility with older MS-DOS utilities and 16-bit Windows applications while presenting modern naming conventions to the user.

To process a file rename that violated the 8.3 standard, the VFAT driver first extracted an 8.3-compliant alias from the new long name using a deterministic truncation algorithm. The system stripped out invalid MS-DOS characters—such as spaces, extra periods, and characters like +, ,, ;, =, [, and ]—and converted all remaining letters to uppercase.

Next, Windows 95 generated the primary stem of the 8.3 alias. It took the first six valid characters of the long name and appended a numeric tail consisting of a tilde and an incrementing digit, starting with ~1 (for example, Financial Report.txt became FINANC~1.TXT). The extension was derived by taking up to the first three valid characters following the last period in the long name.

If another file in the same directory already used the generated alias, Windows 95 initiated a collision resolution check. The system incrementally increased the numeric tail to ~2, ~3, and so on. If the number of collisions reached double digits (such as ~10), the system shortened the initial stem to five characters (e.g., FINAN~10.TXT) to ensure the total name before the extension never exceeded eight characters.

On the physical disk level, Windows 95 stored this dual-identity structure within the FAT directory table by combining legacy and hidden directory entries:

• The SFN Entry: The newly calculated 8.3 alias was stored in a standard 32-byte directory entry. This entry retained the standard file metadata, including starting cluster, file size, timestamps, and file attributes.
• The LFN Entries: The actual long name was broken into 13-character Unicode chunks and stored in reverse order in additional 32-byte directory entries immediately preceding the 8.3 entry.

To prevent older MS-DOS disk utilities (such as CHKDSK or defragmenters) from misinterpreting these extra LFN entries as corrupted files or orphaned fragments, Windows 95 assigned them a specific combination of attributes: Read-Only, Hidden, System, and Volume Label (attribute byte 0x0F). Because standard MS-DOS systems recognized this combination as an impossible file state, legacy tools safely ignored the LFN records while interacting directly with the 8.3 alias.

When a rename operation concluded, Windows 95 purged the old LFN entries, calculated the new alias, verified that no namespace collisions existed, wrote the new sequence of LFN records, and updated the master 8.3 record to reflect the new state.