Feature request: Config on USB

[rhester72]

If USB (or NVME, or...) is enabled, would it be possible to read/maintain the ReplayOS config on that device vs. SD card?

The use cases:

• Upgrading ReplayOS would not require reconfiguration except to point at the alternate storage on first boot and reboot, at that point the configuration on the alternate storage would be used
• If the user has multiple (for example) USB drives for different functions (e.g. one for Amiga, one for Saturn, et al), they can maintain separate configurations for each that would be automatically read and used at boot of that particular USB drive

[f8less]

This would require that a config file compare and update be performed upon switch, to determine if missing variables need to be added with new features/settings developments. This may be best achieved by performing a (secondary storage) config backup upon each shutdown, comparing the config file version when storage is retargeted, performing a config replacement + backup restoration (on secondary storage) if a newer version is on the SD card, and finishing with a required reboot after the storage switch operations complete. This would also create the opportunity to perform a config restore upon corruption or perform a config settings change reversion if not happy with changes made.

[rhester72]

I'm not thinking anywhere near that complilcated.

One-line check of the SD card config to see whether external (USB, NVME, whatever) storage is enabled. If so, consider the external config primary and read/update it as necessary. If there is no external storage, read/write the config on SD.

There's no expectation anything be kept in sync - in fact, it's critical they not be synced, so that you can have (potentially very) different configurations for internal vs. each external storage device.

[f8less]

The problem with that in an your upgrade case noted is that the config won't align with ReplayOS if there are new variable additions, as happened with 1.4.0.

[rhester72]

Certainly - just like it doesn't today, and the solution is exactly the same. Obviously configuration elements that literally didn't exist before will be defaulted as the config is read, there's no getting around that. That doesn't reduce the value of the request.