Repository navigation
Fixed
backupandsnapshotrefuse a destination that names the source's own-wal,-shmor-journalfile (exit code1,Destination is the -journal file of the source database: ...). SQLite treats such a file as the source's write-ahead log, shared-memory index or rollback journal, so a backup published under that name would be reset or deleted by the next application that opens the source.- A destination that is a dangling symlink is now reported as
Destination already exists(exit code1) before the source is opened, instead of after a full copy when the final no-clobber link failed. - The SHA-256 fingerprint and size are now computed from the synced temporary file before publication. A SIGINT, SIGTERM or SIGHUP that arrives while a large backup is being hashed therefore removes the temporary file and publishes nothing, as documented; previously hashing ran after publication.
- The temporary name is removed before the destination directory is synced, so the single directory sync makes both the new name and the removal durable. Once a backup is reported complete, a crash can no longer leave the hidden temporary link behind; previously its removal was never synced.
Changed
- The private temporary database is written with
journal_mode=OFFandsynchronous=OFF. It is discarded on any failure and still passesquick_checkand an explicit fsync before publication, so the rollback journal and SQLite's commit-time syncs were redundant work. Measured on btrfs on SSD (Linux x86_64, load average about 14 on 12 threads, medians of two interleaved series): a 16 MB backup takes 80-84 ms instead of 103-123 ms and a 100 MB backup 369-371 ms instead of 406-442 ms. elapsed_msof a backup now also covers hashing, which runs before publication.
Full Changelog: v0.4.0...v0.4.1