50g: copy all stored objects to SD card individually

[DavidM]

(10-14-2016 09:22 AM)matthiaspaul Wrote:  There isn't much you can do about [case sensitivity] within the limits of the original file system, but this approach will create problems when you want to restore the contents on the calculator later on - how should the calculator decide if the number was a regular part of the name or a suffix? Possibly, a more refined solution would be to copy the approach used in newRPL - it also uses tilde suffixes for the SFNs (short file names), but adds dots to the LFNs (long file names).

My first implementation included storing a log file which shows the "before and after" object names, which could be used (and possibly automated) to match the new names to the old where clarification is needed. The initial focus for this wasn't really in the area of backups so much as copying the discrete objects to an external medium. I haven't really thought much about automating the reverse process, as I have mostly thought of this as a one-way function. For purposes of backing up, my personal preference is to use a completely different approach anyway. I suppose that's why I didn't see this in that context.

Also, I should probably note that I'm using SysRPL for this. I'm not aware of any support it provides for manipulating the SFNs and LFNs independently when copying. If anyone knows how to achieve this with SysRPL, I'd be interested in knowing it. This may be possible while using HPGCC, but that's not an option I'm interested in pursuing at this point.

(10-14-2016 09:22 AM)matthiaspaul Wrote:  The FAT file system itself is character set agnostic, you can store file names in any OEM character set you want for as long as the operating environment (and the user) is able to cope with the possibly strange looking characters.

And therein lies one of the problems I ran into, and it's why I implemented the translation to the "$xx" sequences in the first place. I originally copied the objects over with the ID names passed through without translation, but quickly discovered that my Win7x64 computer steadfastly refused to delete any of the objects that had "special" characters in the names. I didn't take the time to track down exactly which characters caused the problem, but I know that the problem went away when I started replacing the characters with the hex codes. So at least for my specific set of systems, leaving those characters untranslated is not a viable option. I don't have the ability to see if the same issue crops up on other platforms that access the SD card, so I'm not sure if this is only a Win7 issue.

I was planning to create a "renaming" function in the library that would reverse the character translation process for calculator-based objects, as I anticipated that it would be fairly simple to do. That wouldn't include the suffix handling discussed earlier, though. There'd still be a need to deal with that in some reasonable way.

(10-14-2016 09:22 AM)matthiaspaul Wrote:  The VFAT long file names should be converted to Unicode. See https://en.wikipedia.org/wiki/RPL_charac...age_layout for a suggested translation table.

I'd be surprised if this is doable via SysRPL. I simply haven't seen any support for lower-level access to the SD card functions. My gut tells me it's probably built into the ARM side of the house instead of the Saturn-accessible code, but I've learned the hard way not to rule too many things out on these systems. :-)

Thanks for responding! You've provided much food for thought, including whether there's much merit to pursuing this at all given the tools I'm limited to. I still feel like the concept has value, especially when considering the original poster's situation (needing to combine the contents of multiple units). But the effort to complete it may not match the utility gained. There are still other ways to do it that aren't significantly less convenient.