Backup rotation scheme for preferences.xml

[simon04]

Currently, JOSM only keeps one preferences.xml_backup which is overridden after each save, sometimes leading to corrupt files (e.g. see #18569)

JOSM could keep a bunch of backup files named preferences.YYYY-MM-DD.xml, and delete older files according a backup rotation scheme, such as keeping

• one backup file older than 1 hour, and,
• one backup file older than 1 day, and,
• one backup file older than 3 days, and,
• one backup file older than 1 week, and,
• one backup file older than 1 month, and,
• one backup file older than 1 year.

​https://en.wikipedia.org/wiki/Backup_rotation_scheme

[stoecker]

Don't overdo it. This happens seldom and it's not an application task to setup a backup strategy for lazy users.

I recently implemented a scheme which I believe to be a reasonable compromise.

• Original file
• First Backup
• Second Backup

First Backup is created when rewriting the original file. Second backup gets first backup in this case, but only if the size of first and second differ. For JOSM it could probably be another rule like that it must be at least 2 days old.

Probably more helpful would be a "prevent writing config" mechanism like loading the current config and comparing it with the new one. And only save the file at all when it really changed. That drastically reduces the changes to corrupt the config.

[simon04]

I don't think the implementation is overly complicated:

1. List all preferences.YYYY-MM-DD.xml
2. Parse date
3. Sort descending
4. Filter files according to the scheme
5. Delete files not matching 4

[skyper]

See #22376 for a ticket about losing the preferences.