Page Comparison

...

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-4the figure above). None of these, are valid characters (which allows backward compatibility).
• 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).