As of Version 5.0 MagiC supports a VFAT-XFS, with whose help long filenames in Windows95 format can be used on the Atari.
Advantages of this concept:
Existing partitions need not be reformatted; the long filenames
are thus available directly
Files created in this way may be exchanged directly between
MagiC and Windows95 (or higher), and the use of such files is also
possible without an installed VFAT-XFS (important in case one boots
without MagiC at times, for instance)
As VFAT is based on the FAT concept, simple implementation was
possible without any appreciable memory overheads
Disadvantages of this concept:
VFAT has inherited all problems from FAT, so the known cluster
fracturing also exists under VFAT, for instance
There are more modern concepts that are both faster and safer
On the Atari there are at present no programs that can repair
volumes with long filenames; these would have to delete all the
filename entries that are incomplete, or followed by a wrong main
entry
Technical description of the VFAT system:
typedef struct { BYTE head; /* Bit 0..4: Number, Bit 6: Endofname */ UBYTE name1[10]; /* 5 Unicode characters */ BYTE attr; /* Attribute (0x0f) */ BYTE unused; /* Unused at present */ BYTE chksum; /* Checksum of the short name */ UBYTE name2[12]; /* 6 Unicode characters */ WORD stcl; /* First cluster (0) */ UBYTE name3[4]; /* 2 Unicode characters */ } LDIR;
Note: Here head is for the first entry e.g 0x01, for the second 0x02 and for the third 0x43, if the name requires three entries.
One can store 13 characters for each entry. The entries with the long filename always lie immediately before the main (8+3) entry. The Unicode characters are in the Intel format. In the last entry, any unused characters after the NULL-byte are filled with 0xff, 0xff. The order of the entries is reversed, i.e. the last 13 characters of the long name lie physically in the first position. The last directory entry, which is flagged by a set bit 6 in the head field, lies physically in the first position.
The component stcl is always zero; chksum is calculated from the short name (in an internal format) through right-rotation in turn of the previous result and addition of the 11 characters. Linux uses the field unused to store flags for upper/lowercase. The current Windows version however always writes zeros to this field, and MagiC behaves in the same way. Further notes:
The renaming of files with identical names apart from
lower/upper case is possible. Example: By renaming 'test.txt'
to 'TEST.TXT', the long name is discarded automatically.
The conversion Unicode <-> ASCII is implemented according
to the NVDI mapping
If a file is copied from a VFAT partition with long filenames
enabled to one with a normal FAT (where they are not), its name will
be truncated to the 8+3 format. Example: Copying a file
'longfilename.txt' to a FAT partition will make it appear in the
directory as 'LONGFILE.TXT'. If an attempt is then made to copy the
file 'longfilenameS.txt' to the same directory, the usual name
conflict dialog will appear, inviting the user to rename the copy to
avoid duplicating a filename.
If the parition type is changed from VFAT to normal FAT (using
VFATCONF.PRG, say), any long filenames will be truncated; this is
indicated by a tilde ' ' character followed by a numeral at the end of
the shortened name. If two or more such files start with the same
characters, the numeral will be incremented each time.
Example: A directory containing 'longfilename.txt' and
'longfilenameS.txt' when changed from a VFAT to a FAT partition will
display 'LONGFI 1.TXT' and 'LONGFI 2.TXT'. The same applies to
directory names.
In the creation of the short name, spaces are replaced by under
scores. Example: 'Wassili Kandinsky.app' -> 'WASSILI_.APP'.
The VFAT-XFS can also move folders within the directory
structure (irrespective of whether long names are allowed or not).
See also: MagiC's XFS-concept VFATCONF