50g: copy all stored objects to SD card individually

[DavidM]

(10-15-2016 12:01 PM)matthiaspaul Wrote:  Did Windows (Explorer or CMD?) at least display those special characters correctly, or did it display some junk instead? ...not normally displayed by Explorer, but displayed with DIR /X under CMD

I was using Explorer at the time. I'm not sure which code page was used for the character mapping, but 437 would be one possibility. The 50g "→" character was translated to "ì", which would fit that scenario. I seem to use that character in a lot of object names.

As an experiment, I just created an object on the SD card (from the 50g) named "A→B" using the following steps:

Code:

12345
:3:"A→B"
STO

The 50g was happy to do so, and the Filer shows the object at the root level of the card as expected (with the → shown correctly, of course).

Removing the card and putting it into my Win7 machine is where things get more interesting. Viewing the contents of the card with Explorer shows a file named "AìB", but the file can neither be read nor deleted. Windows reports that the file can't be found when those operations are attempted.

Executing "dir /x" from a command shell lists the file as having no SFN at all, and "AŹB" as the LFN (it would appear that the command shell uses a different codepage for translation than Explorer). The command shell couldn't find the file for deletion or copying, though. I tried del, copy and xcopy, all of which failed.

Then, the plot thickens. I tried another experiment, this time using the ID "AAAAA→BBBBB". The same codepage translations resulted on my Win7 system, but now there was also a SFN listed for the file. Deletion and copying on the Win7 system worked as expected for that file.

Further experimentation seems to show the following, but my limited sample isn't enough to assert these as general conditions -- just specifics that matched my test.

When creating files for the SD card FAT file system, the 50g:
- always created a LFN
- created a SFN when the LFN was longer than the 8.3 standard
- created a SFN when the LFN contains characters with mixed case

If the file on the SD card had no SFN AND it also contained a "→" character, the file could not be read or deleted by my Win7 system. I will attempt to try some other "high ascii" characters to see if those also cause problems.

Objects copied by my prototype were all OK because the "problem" characters were translated to "acceptable" ones for Win7 to do what it needed when no SFN existed.

(10-15-2016 12:01 PM)matthiaspaul Wrote:  If the LFNs were displayed as garbage, the calculator probably just passed the file name through untranslated (which would be okay for the SFNs, but obviously not for LFNs).

This has been my assumption all along. I believe the support for FAT that's built-in to the 49g+/50g is minimal (at best).

(10-15-2016 12:01 PM)matthiaspaul Wrote:  Yet another approach used by some embedded systems to save the memory for a translation table is to just replace characters above 127 by some dummy character like "_". However, in this case, Windows should have no problems to handle the files.

That was the same character I initially chose when I was first experimenting with this. I quickly found, though, that doing this kind of simple swap-out caused an increase in the number of ID collisions. So I opted for the more specific hex code translation.