Is my Atari Falcon's filesystem messed up?

Question

I use the Cecile driver for the Kingspec DOM (basically an IDE flash drive0 in my Atari Falcon. I've noticed on occasion that in file dialog boxes (save, open etc.) I sometimes see weird files, called things like "AD", and "AF" or some other two character combination.

These aren't visible in the GEM Desktop, and they don't seem to cause any issues, but it does make me a little concerned. Does anyone know if these are a sign of a bad filesystem or just some strange artefact from the driver?

Answer 1

To expand on @RicoPajarola's comment, this is almost definitely the software not properly handling files with long (or lowercase / etc.) filenames on a FAT filesystem.

Originally, the FAT filesystem only supported filenames of up to 8 characters (+ up to 3 characters for the extension).
Also - lowercase letters, spaces and unicode weren't supported.

Later, long filename support was added to FAT in a way that will fit the longer names within the restrictive structure of the original FAT, thus allowing older programs and operation systems that aren't aware of long filenames to continue functioning, usually (but as you observed - not always) without any bugs.

FAT stores a fixed-size entry containing the name and attributes (e.g. size, times) for each file in a directory.
With long filename support, this fixed-size entry remains unchanged and contains the file's short name (E.g. turning "MyLongFileName.dat" to "MYLONG~1.DAT").

Instead, one or more special "long filename" entries are added before the "real" entry, and these contain the file's long name. These entries are marked as hidden, read-only, system, volume id entries - in the hopes that most existing software will realize it should not display them.

As for why it's almost certain this is indeed the issue in your case (despite the lack of details):
Where a normal entry has its first three characters of the name, a long filename entry has:
1. The index of the long filename entry plus a "this is the last such entry before the real entry" indicator.
2. The least significant byte of the first character.
3. The most significant byte of the first character. (Since characters in long filename entries are in the UTF16 Unicode encoding, and thus take 2 bytes, compared to the 1-byte ANSI characters of the real entries)

In the common case, when a long filename is in English and fits in 13 unicode characters, the above 3 characters are:
1. 'A' (which has a value of 0x41 (or 65 = 64 + 1), interpreted as index 1 with the last entry indicator (0x40 = 64) set.
2. The first character of the filename. (Since English Unicode characters match their ANSI/ASCII counterparts)
3. A null character (value of 0), which would cause most programs to assume the name is over.

This is what gives names like the 'AD' and 'AF' you mentioned.
These "bad" names will almost always (unless you're using non-English Unicode characters) be two character long and will often start with 'A'. (Though if longer long filenames are used, the bad names can also start with 'B', 'C', etc. - and perhaps also with some odd characters for the "non-last" entries whose first character is a control character)

These entries will likely have odd times and an odd size displayed as well, since long filename entries store more characters where the times & size normally are.

To summarize - no, your filesystem is not corrupted, the software simply isn't able to handle it properly.
It's best not to interact with the "bad" entries (it should be harmless in FAT12/FAT16 filesystems, but I'm not so sure about FAT32 since some of the characters are where it stores the offset to the file data), but it should most likely be fine to continue interacting with the good entries, ignoring the bad ones.
(Of course, backing it up beforehand is always a good idea)

Now, you didn't give many details, so it is theoretically possible that 'AD' and 'AF' are just unfortunate examples and the actual filesystem and issue are different, but until other info comes to light, this is the overwhelmingly likely possibility.

(Source: Technical FAT specification)