In the original version of FAT, files could only carry short “8 dot 3” names, with eight or fewer characters in the main name and three or fewer in its extension. The valid characters in these names are letters, digits, characters with values greater than 0xFF and the following:

$ % ‘ - _ @ ~ ` ! ( ) { } ^ # &

In µC/FS, the name passed by the application is always verified, both for invalid length and invalid characters. If valid, the name is converted to upper case for storage in the directory entry. Accordingly, FAT file names are not case-sensitive.

Later, in a backwards-compatible extension, Microsoft introduced long file names (LFN). LFNs are limited to 255 characters stored as 16-bit Unicode in long directory entries. Each LFN is stored with a short file name (SFN) created by truncating the LFN and attaching a numeric “tail” to the original; this results in names like “file~1.txt”. In addition to the characters allowed in short file names (SFN), the following characters are allowed in LFNs:

+ , ; = [ ]

As described in section E-7 “FAT Configuration”, support for LFNs can be disabled, if desired. If LFNs are enabled, the application may choose to specify file names in UTF-8 format, which will be converted to 16-bit Unicode for storage in directory entries. This option is available if FS_CFG_UTF8_EN is DEF_ENABLED (see Appendix E, “Feature Inclusion Configuration”).

Entries for files that have long file names

To allow FAT to support long file names, Microsoft devised the LFN directory entry, as shown in Figure 12-4.

An LFN entry is essentially a workaround to store long file names in several contiguous 32-byte entries that were originally intended for short file names.

A file with an LFN also has a SFN this is derived from the LFN. The last block of an LFN stores the SFN that corresponds to the LFN. The two or more preceding blocks each store parts of the LFN. Figure 12-4 shows four “blocks”

• The first block shows the names for the fields in an LFN entry; the actual LFN entry is shown in the next three blocks.
• The middle two blocks show how FAT stores the LFN for a file named “abcdefghijklm.op” in two 32-byte FAT table entries.
• The final block shows how FAT stores the SFN derived from the LFN. In this case, the SFN is “abcdef~1.op” Note that the “.” of an 8.3 filename is not actually stored.

The final 32 bytes for an LFN entry has the same fields as the 32-byte entry for (in this example) a file with a SFN of “abcdef~1.op”. Accordingly, it is able to store, in addition to the file’s SFN, the properties (creation date and time, etc.) for file “abcdefghijklm.op”.

• Together, the three blocks make up one LFN directory entry, in this case the LFN entry for file “abcdefghijklm.op”.

A long file name is stored in either two or three 32-bit entries of a directory table:

• If three entries are needed to store the long file name, byte 0 of the entries carry order numbers of 0x43, 0x02 and 0x01, respectively. (Byte 0 is labelled “Ord” in Figure 12-4). None of these, are valid characters (which allows backward compatibility).
• If two entries are needed (as in Figure 12-4), byte 0 of the entries carry order numbers of 0x43 and 0x01, respectively.
• In entries that store part of a LFN, byte 11, where the Attributes value is stored in a SFN, is always 0x0F; Microsoft found that no software would modify or use a directory entry with this marker.
• In entries that store part of a LFN, byte 13 contains the checksum, which is calculated from the SFN. FAT’s file system software recalculates the checksum each time it parses the directory entries. If the stored checksum is not the same as the recalculated checksum, FAT’s file system software knows that the SFN was modified (presumably by a program that is not LFN-aware).