As we know that a directory entry is marked with the combination of read-only, hidden, system, and volume label attributes Bits. Likely, if the attribute byte of Directory Entry holds the value 0FH the enumeration functions built into all existing versions of DOS and all Pre-Windows 95 versions of Windows will skip over that directory entry as if it were not there.
Then, the solution was to store two names for every file and subdirectory, a short name that is visible to all applications and a long name that is visible only to Windows 95 (and Later) applications and to applications that have been rewritten to add support for long filenames. Short filenames are stored in 8.3 formats in conventional 32-byte directory entries.
We have already discussed that Windows creates a short filename from a long one by truncating it to six uppercase characters and adding "~1" to the end of the base filename.
If there is already another filename with the same first six characters, the number is incremented. The extension is kept the same, and any character that was illegal in earlier versions of Windows and DOS is replaced with an underscore.
The Long filenames are stored in specially formatted 32-Byte Long File Name (LFN) Directory Entries marked with attribute bytes set to 0FH. For a given file or subdirectory, a group of one or more Long File Name directory entries immediately precedes the single 8.3 directory entry on the disk.
Each Long File Name directory entry contains up to 13 characters of the long filename, and the operating system strings together as many as needed to comprise an entire long filename.
For a Long File Name directory entry, filenames are stored in Unicode format, which requires 2 Bytes per character as opposed to 1 Byte of ASCII. Filename characters are spread among three separate fields:
- The first 10 Bytes (five characters) in length,
- The second 12 Bytes (six characters),
- The third 4 Bytes (two characters).
The lowest five Bits of the first byte of directory entry hold a sequence number that identifies the position of directory entry relative to other Long File Name directory entries associated with the same file.
If a long filename requires three LFN directory entries, the sequence number of the first will be 1, that of the second will be 2, and the sequence number of the third will be 3 and Bit 6 of the first Byte of third entry is set to 1 to indicate that it is the last entry in the sequence.
The attribute field appears at the same location in LFN directory entries as in 8.3 directory entries because the file system does not know which type of directory entry it is dealing with until after it examines the attribute byte. The starting cluster number field also appears at the same location, but in LFN directory entries its value is always 0. The type indicator field also holds 0 in every long filename.
One of the problems with long filenames is that they consume more disk space than short ones. That is not a big deal when long names are stored in subdirectories, because as long as disk space is available, subdirectories can grow to accommodate added directory entries but the maximum number of directory entries available in the root directory is fixed, and long filenames waste space in the root directory which is limited in size.
Now for Example, if the root directory of a hard disks contains at most 512 directory entries, because a 128-character name requires 11 entries, 10 for the long name and 1 for the short name, you could create only 46 files and subdirectories in the root directory if each were given a 128-character name.
The problem goes away for FAT32 also because the root directory under FAT32 can grow as well because in FAT32 system the root directory is treated as a File which can grow in size.