Page Comparison

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.

...

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” 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.LFN directory entry.

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 The figure above 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.

...

• 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 compatibilitythe figure above). Although 0x43 is a valid character, an SFN-only FAT implementation will not mistakenly try to interpret it as the first letter of an entry name. This is due to the fact that LFN directory entries have special attributes (byte 11 set to 0xF) that make them appear as volume labels to SFN-only FAT implementations (so that they are simply ignored during regular file or directory lookup).
• If two entries are needed (as in Figure 12-4figure above), 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).