Suite (all I think) - Backup/Restore tool should not act on system files

[spoke2570]

I noticed while updating that the options for backup/restore seem possibly at odds with the updater. It looks like one can restore an older version of system bitmaps to a newer version of ETHOS. Backup/restore options for system bitmaps should be removed.

The audio label is only unclear as to whether it saves the user defined files, secondary voices, default system voice or what combination. This should be clarified.

I feel like the backup/restore tool should not touch file sets that are brought in by the updater.

[Nicholas-Luoyi]

I think this is a good point. And operations on the system bitmaps and audio will take a lot of time

[spoke2570]

I feel like my position as presented is a little short sighted. I see where an easy return-to-some-previous-state is a desirable feature, but a tool that complete would basically be a snapshot of the discs in play from som previous point. I feel like most folks going in that deep are adept at doing this manually.

[strgaltdel]

just my 2 cents

A restore should always be a restore, and it should be possible to generate a full restore from a full backup.

The software cannot know the reason why the user is performing a restore and should generally offer all options. If writing audio or bitmaps is no longer allowed, and there was a (now repaired) logical error on the target drive, the user may not be able to revert to the backup state despite a suite restore.

One possible solution could be: The backup could potentially generate/suggest the filename in such a way that a "revision-label" with the revision number is included. "Ethos_20240702-2148.010509.zip" for ethos 1.5.09

The suite knows the firmware revision of the tx and can check the plausibility before the restore, as long as the user has not manually changed the rev-label in the filename. If the user deletes or adjusts the label when naming, it is at their discretion, and the plausibility will no longer be checked. If rev-label exists and a check fails, a popup can appear, indicating whether the user still wants to proceed. With some documentation on the purpose of a new naming convention, this should be understandable.

I have not yet dealt with the suite's backup/restore function, but another possible solution could be to automatically zip a "shadow file" containing the release status(e.g. as filename) during the backup, depending on "zip-API". Then this file should be checked/audited first during the restore.

[spoke2570]

Comparatively: when I brick my laptop (and I am good at that) I need to get a working operating system on it before I can do a restore of my files, settings, etc. I would propose that the updater handle the default things like reinstalling an OS on my laptop and the restore do the custom things, settings and such.

One of the big reasons that I don't use many backup restore tools is that they are not usually clear about what they do and where they do it. I would most of all like this one to be clear and user friendly

[Nicholas-Luoyi]

I propose I keep those two selections on the dialog. But by default, these two selections won't be checked.

[spoke2570]

I like the simplicity of your solution, we still need to separate user and system sounds, now. I just put on 1.5.8. (Works really well BTW super fast model image load, no app quit warnings yet)

In a spot where a user backs up the sounds from version 1. Version 2 gets a bunch of new sounds from its developers. User upgrades to version 2, then restores from version 1. The new version 2 sounds are gone, but at least the ones the user laboriously made are saved.

I would like to see the sounds that land in the default folder be considered system sounds and given their own component level in the backup/restore tools, like the bitmaps