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?

  • 1
    Is the drive using FAT (either standard MS-DOS variety or Atari variety) or some other filesystem? Do the files show up in several file pickers (e.g. UIS III and the like), or just one? Do they show up when the drive is plugged into a non-Atari device that can read the filesystem? Commented Jun 14, 2016 at 16:48
  • 1
    If this is a FAT filesystem, these might be long filenames that the program doesn't understand, but you're not giving us enough information to figure this one out for sure. What filesystem are you using, what are the exact filenames you expect versus what you see (or a screenshot). Commented Aug 3, 2016 at 22:39
  • 1
    Could you post a list of combinations that appear, or the list of letters that appear? (Is it limited to A-F, maybe something to do with hex codes, perhaps a deleted file...)
    – wizzwizz4
    Commented Aug 31, 2016 at 10:21
  • I've been meaning to circle back on this, my Falcon's been on the shelf for a month or so. I suspect you're onto something here @wizzwizz4, now you mention it I think they are all single-byte hex values.
    – Matt Lacey
    Commented Sep 1, 2016 at 2:54
  • Which file system is it using? I might be able to find something while searching through the language specification.
    – wizzwizz4
    Commented Sep 1, 2016 at 8:33

1 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)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .