The problem
The RestoreBackup function performs a raw file copy over the live database. It does not check if there is an active running timer, meaning a restore will silently obliterate an in-flight time entry. Additionally, if the database ever runs in WAL mode, a stale tmpo.db-wal or tmpo.db-shm file alongside the restored file can corrupt or shadow the restored data.
Release version
0.8.6
Operating system
macOS
Steps to reproduce the behavior
- Run
tmpo start "Test"
- Run
tmpo backup restore and select a backup.
- The running timer is destroyed without warning.
Screenshots
No response
Additional context
Backup creation currently checks for running timers; restore should implement the exact same check. To prevent WAL corruption, sidecar files should be deleted during restoration, or the restore should happen via VACUUM INTO semantics in reverse.
The problem
The
RestoreBackupfunction performs a raw file copy over the live database. It does not check if there is an active running timer, meaning a restore will silently obliterate an in-flight time entry. Additionally, if the database ever runs in WAL mode, a staletmpo.db-walortmpo.db-shmfile alongside the restored file can corrupt or shadow the restored data.Release version
0.8.6
Operating system
macOS
Steps to reproduce the behavior
tmpo start "Test"tmpo backup restoreand select a backup.Screenshots
No response
Additional context
Backup creation currently checks for running timers; restore should implement the exact same check. To prevent WAL corruption, sidecar files should be deleted during restoration, or the restore should happen via
VACUUM INTOsemantics in reverse.