Names of ObectStore files. 8 char limit? Why not the full name?

I have a watchface called "simplewatch" (simplewatch.prg), and am adapting it to use an object store.

The code is working, but I notice that the name of the .STR seems to be changed to <8 char>.STR, so for example, the OS is called "SIMPLE~1.STR"

Seems this could cause a conflict if something else using an OS started with "simple..".

Side loaded app, on the va, FW 2.90.

Why not use the full name so there is no possible conflict, and so it maps to the .prg name and the .txt name (for logs)?

I believe it's using a FAT filesystem:

$ mount
/dev/disk3 on /Volumes/GARMIN (msdos, local, nodev, nosuid, noowners)


But things like .prg files and .txt files are not limited to the 8x3 (old dos) format. It's specific to the str files...... This seems to be a bug in how the names are used. From the app store, the prg has an 8 digit string vs the name, so the 8 digit name would always work for those .str file names. What I describe happens when you sideload something that uses more than 8 characters for a name.

The file system used by the devices is pretty bare-bones. (This saves space for things like ConnectIQ!)

What you are seeing is the 8.3 filename.

An 8.3 filename[1] (also called a short filename or SFN) is a filename convention used by old versions of DOS, versions of Microsoft Windows prior to Windows 95, and Windows NT 3.51. It is also used in modern Microsoft operating systems as an alternate filename to the long filename for compatibility with legacy programs.

...

To maintain backward-compatibility with legacy applications (on DOS and Windows 3.1), on FAT and VFAT filesystems an 8.3 filename is automatically generated for every LFN, through which the file can still be renamed, deleted or opened

...

Although there is no compulsory algorithm for creating the 8.3 name from an LFN, Windows uses the following convention:

• If the LFN is 8.3 uppercase, no LFN will be stored on disk at all.
  
  • Example: TEXTFILE.TXT
  
  
• If the LFN is 8.3 mixed case, the LFN will store the mixed-case name, while the 8.3 name will be an uppercased version of it.
  
  • Example: TextFile.Txt becomes TEXTFILE.TXT.
  
  
• If the filename contains characters not allowed in an 8.3 name (including space which was disallowed by convention though not by the APIs) or either part is too long, the name is stripped of invalid characters such as spaces and extra periods. Other characters such as + are changed to the underscore _, and uppercased[clarification needed]. The stripped name is then truncated to the first 6 letters of its basename, followed by a tilde, followed by a single digit, followed by a period ., followed by the first 3 characters of the extension.
  
  • Example: TextFile1.Mine.txt becomes TEXTFI~1.TXT (or TEXTFI~2.TXT, should TEXTFI~1.TXT already exist). ver +1.2.text becomes VER_12~1.TEX.
  
  
• Beginning with Windows 2000, if at least 4 files or folders already exist with the same initial 6 characters in their short names, the stripped LFN is instead truncated to the first 2 letters of the basename (or 1 if the basename has only 1 letter), followed by 4 hexadecimal digits derived from an undocumented hash of the filename, followed by a tilde, followed by a single digit, followed by a period ., followed by the first 3 characters of the extension.
  
  • Example: TextFile.Mine.txt becomes TE021F~1.TXT.
  
  

Object store files being generated with short filenames is the expected behavior. Any file created by the internal system will only have a short filename. The internal system can only see the short filename for files that were added to the system with a long filename. If you sideload an app, and it's object store, they should have matching short filenames, and the system will match them up properly.

So, the filesystem on the device can only create 8.3 names, but can read/write files that are something like 12.3 (.prg files and .txt files). I think I'll just change the .prg names that use the OS to be 8.3 so that all the names can match....

The device can read/write files with long filenames, but only by accessing them through the short filename. It is slightly safer to stick with 8.3 names, so that is a reasonable approach.