50g: copy all stored objects to SD card individually

[matthiaspaul]

(10-17-2016 04:47 PM)Claudio L. Wrote:  

(10-16-2016 07:26 PM)matthiaspaul Wrote:  :3:"SPECIÄL" STO no reason to create a LFN entry but some system may do

There's one reason: The character >127. Creating an LFN is the only way to store it as Unicode. I modified newRPL to always create LFN's in cases like this, just to eliminate the ambiguity of using CP translation. Technically not needed if you are willing to put up with old CP mess, though.

I agree, at least in this context. (I personally try to avoid *VFAT* LFNs whenever possible, for I consider the way they were retrofitted into the FAT filesystem a design "nightmare". There would have been more robust methods to integrate long file names into FAT while still maintaining full backward compatibility - and without speed or size penalties. But keeping FAT volumes free of VFAT LFN entries only makes sense for as long as the whole medium can be kept free of them realistically (for example on local partitions using partition IDs not recognized by systems using VFAT LFNs). In the case of an exchange medium of a calculator using a custom character set it would be unrealistic to maintain this goal. Actually, given that the RPL character set is based on ISO/IEC 8859-1 and thus many codepoints are identical to Unicode codepoints, being able to store characters in Unicode is highly desirable - assuming a bug-free implementation... ;-)

So, my comment wasn't meant to imply that this would be a bad idea, just that it is technically not required from the viewpoint of the filesystem. And in fact, as we can see from the DIR /X output above, the calculator does not create a LFN entry in this case.

Greetings,

Matthias