[Settings] Back up the settings folder before migrating (#7386)

* [Settings] Back up the settings folder before migrating

The per-file settings migration only preserved global.ini, as
global.ini.old. Everything else the migrations write was overwritten in
place with no way back: the legacy migration and the 17 per-domain
migrateXxxSettings functions all write straight into the per-domain .ini
files, so any of them that got a key mapping wrong silently replaced a
working file. The re-migration path is the sharpest case, because
migrateSettingsFromGlobalIni() runs again whenever an older build wrote
non-sentinel keys back into global.ini, and those values then land on
top of per-domain files the user had already edited.

Snapshot the whole settings folder before either migration runs, into a
timestamped sibling settings-backup-<yyyyMMdd-HHmmss>. A sibling rather
than a child, so a backup is never copied into the next backup and the
"Open Settings Folder" action keeps showing only live files. Keep every
snapshot; settings files are kilobytes, so growth is not a concern.

SettingsMigration::isMigrationPending() gates the copy so a normal start
creates nothing. It reuses the same condition migrateSettingsFromGlobalIni()
uses to decide whether it has work, factored into a shared helper so the
two cannot drift, and it ignores the legacy migration on an empty profile
where that migration only writes its sentinel. The backup itself skips a
folder whose files are all empty, which covers a fresh profile whose
global.ini was created but never written.

A failed copy logs a warning and returns an empty path rather than
aborting the migration, since a full disk or an unwritable data folder
must not leave the client unable to start. global.ini.old still works as
the single-file escape hatch.

Document the folder layout, the automatic backups, and the fact that
migrations only run forwards, so users know to copy the settings folder
before downgrading to a version that cannot read the per-group files.

* [Client] Match the desktop file name case for the portal app ID

QGuiApplication::setDesktopFileName() was given "Cockatrice"/"Oracle"
while the installed desktop entries are cockatrice.desktop and
oracle.desktop. Linux paths are case-sensitive, so xdg-desktop-portal
failed the app-info lookup for "Cockatrice" and Qt warned on every
QDesktopServices call that it could not register with the host portal.
The same string becomes the xdg-shell appId, so the window icon lookup
failed on Wayland for the same reason.

---------

Co-authored-by: Lukas Brübach <Bruebach.Lukas@bdosecurity.de>
This commit is contained in:
BruebachL 2026-10-03 14:59:58 +02:00 • committed by GitHub
parent b8b81170bf
commit 3aba1ef929
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
8 changed files with 372 additions and 16 deletions

View file

@ -0,0 +1,43 @@
@page settings_folder Settings Folder and Backups
Cockatrice keeps all of its preferences in a settings folder on your computer, one `.ini` file per
group of settings (appearance, sound, decks, and so on). Open it from the main window via
Help → Open Settings Folder.
# The Per-File Migration
Older versions of Cockatrice stored every setting in a single `global.ini` file. The settings were
split into per-group `.ini` files so that unrelated groups no longer share one file. The first time
you start a version that uses the new layout, your settings are moved into the new files
automatically and nothing is lost. The old `global.ini` is kept next to the new files as
`global.ini.old`.
# Automatic Backups
Both migrations overwrite files in the settings folder in place, so before either one runs,
Cockatrice copies the whole folder to a timestamped backup folder:
```
<data folder>/settings-backup-20261002-193000/
```
The backup folder sits next to the settings folder, not inside it. Every backup is kept, so if
settings ever end up wrong you can compare against, or copy files back from, the earlier snapshot.
Backups are only created when a migration actually has work to do, so a normal start creates
nothing.
# Downgrading
Settings migrations only run forwards. If you ever go back to an older version of Cockatrice, that
version does not read the new per-group files, so it will start with default settings.
Before downgrading, copy your settings folder somewhere safe, for example:
- Linux: `~/.local/share/Cockatrice/settings/`
- macOS: `~/Library/Application Support/Cockatrice/settings/`
- Windows: `%LOCALAPPDATA%\Cockatrice\settings\`
Portable installs keep the settings folder in the `data` folder next to the executable.
Copying that folder back after downgrading restores your settings. The automatic backup folder from
the migration is there as a second copy of the same data if you need it.