50g: copy all stored objects to SD card individually

[DavidM]

(10-15-2016 07:28 PM)Claudio L. Wrote:  ...SDLIB (included in SDFiler, never released separately but doesn't need the filer to work). The SDLIB library provides commands you can use from userRPL/sysRPL.

One of the reasons I started this thread in the first place is that I knew if there were any responses, they would bring new ideas into the mix. I was already vaguely familiar with SDFiler, but to be honest never went through the documentation enough to realize how SDLIB was at the heart of it.

One of the reasons I had thought of this app as a "one-way street" is that I knew there was no straightforward way of getting a directory listing from the SD card (short of using SDLIB ). Lacking that, retrieving arbitrary lists of files from the SD card would be quite messy, and would have to be built on top of some very restrictive assumptions.

I had originally thought that copying the files back to the calculator(s) would be done using Conn4x. That said, I realize that some people can't use (or prefer not to use) that app, and copying the files back from the SD card in their new hierarchy would be very convenient. That would certainly improve the usefulness of the app, and could open up other possibilities as well (yes, using it for backups is the first thing that comes to mind).

As an example, I could see a scenario like the following:

Using your computer, arrange your favorite calculator objects into a folder structure on the SD card that might look something like this:

Code:


<root>
    SOMEFLDR
        HOME
            Fldr1
                Obj1
                Obj2
            Fldr2
            ...
        PORT0
            PortObj1
            PortObj2
        PORT1
            PortObj1
            PortLib1
        PORT2
            PortObj1
            PortLib1
            ...

An app could then be utilized to recreate that same structure on the calculator. Different options might include things like wiping out current calculator contents before copying, default actions for when a name conflict occurs (ignore, overwrite, rename), disposition of hidden directory items, and I'm sure a lot of things that would come to mind later.

(10-15-2016 07:28 PM)Claudio L. Wrote:  However, for your case I think I would go with the idea of replacing the names with some heavily sanitized version of the name. Then you include the name back inside the file for proper recovery (a list { name value } as mentioned in other posts sounds very appropriate).

I like the concept of the list for each object, and I would include one more item: a small sentinel value of some kind to identify it as a pre-formatted "object list" appropriate for this app. That would make it easy to determine if the object should be renamed or simply copied over intact with whatever name it already had (possibly still with some translation of ID characters if appropriate).

More things to ponder!