50g: copy all stored objects to SD card individually

[matthiaspaul]

(10-15-2016 04:17 PM)DavidM Wrote:  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

[...]
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.

This observation most likely indicates that (at least) this special character wasn't translated at all by the calculator:

"→" has codepoint 8Dh in the RPL character set. The equivalent character has codepoint 1Ah in codepage 437, 850, 858 and many others, but would be difficult to display in many scenarios as it lies in the control character range.
If the calculator would have translated the character to Unicode this would have resulted in character U+2192 in the LFN.
There are two scenarios for Windows to display an "ì": It could be the result of a character U+00EC in a LFN, or of a code mapping to "ì" in a SFN (which happens to be at codepoint 8Dh in codepage 437, 850, 858 etc.).
If a LFN exists, it would certainly have been used by Windows, but there is no reasonable scenario why the calculator should have translated codepoint 8Dh into U+00EC. By this we can deduct that this file has only a SFN.

Quote: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.

Yes and no.

Yes: Explorer obviously assumes a different codepage for translation than CMD. What codepage is displayed by CHCP under CMD?

No: While it is possible to disable SFNs in NTFS, this is impossible for FAT. Even though Microsoft calls the FAT SFNs "alias names", the SFNs are the *actual* file names, and the LFNs rather than the SFNs are optional. A LFN can be seen as some kind of "extended attribute" loosely attached to the directory entry holding the SFN (and all the other information about the file). A SFN may contain invalid characters and be distorted to the point of not resembling the corresponding LFN any more at all, but it is impossible for a SFN not to exist in the FAT filesystem.

So, basically DIR /X is displaying the SFN as if it would be a LFN if no LFN exists. The file name was short enough to still fit into the 8.3 naming scheme, so it seems the calculator hasn't created a LFN even though the name contains special characters (and this is normally another reason to create a LFN).

Quote: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.

In this case the name was too long to still fit into the 8.3 scheme, so the calculator must have created a LFN.

Was this file displayed as "AAAAA→BBBBB" or "AAAAAìBBBBB" in Explorer?

And how was this file displayed by DIR /X exactly? "AAAAAŹBBBBB" and "AAAAAŹ~1" or something different?

Quote: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

- always created a SFN
- created a LFN when the name was longer than the 8.3 standard
...

Quote: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.

That will be very interesting.

Once we know what rules are used by the calculator, we might be able to derive an "adaptive partial renaming scheme" for your library.

For example, if we knew for sure, that the calculator does not apply any translation at all and that it creates LFNs only for names not fitting into the 8.3 scheme, your library could apply different pre-translations depending on the length of the name:

For names long enough to end up as LFNs on disk, the library could pass through characters 00h..7Fh and (A0h) A1h..FFh and only translate characters 80h..9Fh (and possibly A0h) from the RPL character set using your $xx translation scheme (or another scheme, if we could find something better). Unfortunately, all RPL codepoints 80h..A0h map to Unicode codepoints larger than 00FFh, so, without any translation by the calculator and no low-level filesystem access, it is impossible to enforce better suitable characters on disk.

For names short enough to end up as SFNs, the library could either apply a translation to codepage 437, 850 etc. and remove characters which are not allowed in SFNs. Alternatively, the library could add some dummy characters to ensure that the calculator will also create a LFN for the file. Perhaps the ";" could be used for this purpose as well (for as long as its not conflictive with newRPL - to be sorted out)...

Greetings,

Matthias