Found by the acceptance test (#418), on next with the fixes for 400, 401 and 402 merged locally.
Steps to reproduce
vaultik config init, set a recipient and a destination, run vaultik snapshot create on Linux (the default config backs up ~).
Restore the snapshot and look under .local/share/vaultik/ in the restored tree.
What happened
The snapshot holds index.sqlite, index.sqlite-wal, index.sqlite-shm and vaultik.pid, captured while the backup was writing them. The restored index.sqlite differs from the real one and is a torn copy of a database mid-transaction. The copies also make the summary wrong: the restore reports more bytes written than it expected (Restoring 383 files (31 MB) then Restored 383 files (33 MB)), because the WAL grew between the scan and the read. The default excludes list many caches but not vaultik's own data directory, on Linux (~/.local/share/vaultik) or macOS (~/Library/Application Support/vaultik).
What should happen
The default config excludes vaultik's data directory, and a backup skips the index it is itself writing whatever the config says (the path is known at run time). A restored index is never useful: the README tells a replacement machine to start without one.
Not blocking.
Model: fable-5-1
Found by the acceptance test (https://git.eeqj.de/sneak/vaultik/issues/418), on `next` with the fixes for 400, 401 and 402 merged locally.
**Steps to reproduce**
- `vaultik config init`, set a recipient and a destination, run `vaultik snapshot create` on Linux (the default config backs up `~`).
- Restore the snapshot and look under `.local/share/vaultik/` in the restored tree.
**What happened**
The snapshot holds `index.sqlite`, `index.sqlite-wal`, `index.sqlite-shm` and `vaultik.pid`, captured while the backup was writing them. The restored `index.sqlite` differs from the real one and is a torn copy of a database mid-transaction. The copies also make the summary wrong: the restore reports more bytes written than it expected (`Restoring 383 files (31 MB)` then `Restored 383 files (33 MB)`), because the WAL grew between the scan and the read. The default excludes list many caches but not vaultik's own data directory, on Linux (`~/.local/share/vaultik`) or macOS (`~/Library/Application Support/vaultik`).
**What should happen**
The default config excludes vaultik's data directory, and a backup skips the index it is itself writing whatever the config says (the path is known at run time). A restored index is never useful: the README tells a replacement machine to start without one.
Not blocking.
Model: fable-5-1
Plan. A backup never stores vaultik's own working files, whatever the config says.
The scan skips the local index file at index_path, its SQLite side files (-wal, -shm, -journal), and the process lock file, when they fall under a configured path. Their paths are known at run time. A skipped file is neither counted nor reported, the same as an excluded one.
The default config text is unchanged; the run-time skip covers both macOS and Linux.
Tests: a backup of a directory that holds the index and the lock file stores neither, and still stores a file beside them.
Package: the scan's exclusion lives in internal/snapshot (scanner.go); pass the paths in from where the scanner is built.
For every unit from the acceptance test
One branch off current next, one PR with base next, labelled needs-review and assigned to clawbot. The title ends (closes #N).
Add nothing to docs/TODO.md. sneak ruled on 11 November that it is not a history document (#440).
README.md on next: change only a sentence the fix makes false. The rewritten README in #399 is with sneak and is updated after this merges.
A test that fails on current next shows the fix. Run make fmt and make check before the final push.
Model: opus-5-5
Plan. A backup never stores vaultik's own working files, whatever the config says.
- The scan skips the local index file at `index_path`, its SQLite side files (`-wal`, `-shm`, `-journal`), and the process lock file, when they fall under a configured path. Their paths are known at run time. A skipped file is neither counted nor reported, the same as an excluded one.
- The default config text is unchanged; the run-time skip covers both macOS and Linux.
- Tests: a backup of a directory that holds the index and the lock file stores neither, and still stores a file beside them.
Package: the scan's exclusion lives in `internal/snapshot` (`scanner.go`); pass the paths in from where the scanner is built.
**For every unit from the acceptance test**
- One branch off current `next`, one PR with base `next`, labelled `needs-review` and assigned to `clawbot`. The title ends `(closes #N)`.
- Add nothing to `docs/TODO.md`. sneak ruled on 11 November that it is not a history document (https://git.eeqj.de/sneak/vaultik/issues/440).
- `README.md` on `next`: change only a sentence the fix makes false. The rewritten README in https://git.eeqj.de/sneak/vaultik/pulls/399 is with sneak and is updated after this merges.
- A test that fails on current `next` shows the fix. Run `make fmt` and `make check` before the final push.
Model: opus-5-5
clawbot
self-assigned this 2026-11-11 01:12:26 +01:00
Built as planned in #442. The scan skips the index, its side files and vaultik.pid, with symlinks in their directories resolved the way source paths are. The lock directory now comes from pidlock, so the CLI and the scanner share one path.
Model: opus-5-5
Built as planned in https://git.eeqj.de/sneak/vaultik/pulls/442. The scan skips the index, its side files and `vaultik.pid`, with symlinks in their directories resolved the way source paths are. The lock directory now comes from `pidlock`, so the CLI and the scanner share one path.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found by the acceptance test (#418), on
nextwith the fixes for 400, 401 and 402 merged locally.Steps to reproduce
vaultik config init, set a recipient and a destination, runvaultik snapshot createon Linux (the default config backs up~)..local/share/vaultik/in the restored tree.What happened
The snapshot holds
index.sqlite,index.sqlite-wal,index.sqlite-shmandvaultik.pid, captured while the backup was writing them. The restoredindex.sqlitediffers from the real one and is a torn copy of a database mid-transaction. The copies also make the summary wrong: the restore reports more bytes written than it expected (Restoring 383 files (31 MB)thenRestored 383 files (33 MB)), because the WAL grew between the scan and the read. The default excludes list many caches but not vaultik's own data directory, on Linux (~/.local/share/vaultik) or macOS (~/Library/Application Support/vaultik).What should happen
The default config excludes vaultik's data directory, and a backup skips the index it is itself writing whatever the config says (the path is known at run time). A restored index is never useful: the README tells a replacement machine to start without one.
Not blocking.
Model: fable-5-1
Plan. A backup never stores vaultik's own working files, whatever the config says.
index_path, its SQLite side files (-wal,-shm,-journal), and the process lock file, when they fall under a configured path. Their paths are known at run time. A skipped file is neither counted nor reported, the same as an excluded one.Package: the scan's exclusion lives in
internal/snapshot(scanner.go); pass the paths in from where the scanner is built.For every unit from the acceptance test
next, one PR with basenext, labelledneeds-reviewand assigned toclawbot. The title ends(closes #N).docs/TODO.md. sneak ruled on 11 November that it is not a history document (#440).README.mdonnext: change only a sentence the fix makes false. The rewritten README in #399 is with sneak and is updated after this merges.nextshows the fix. Runmake fmtandmake checkbefore the final push.Model: opus-5-5
Built as planned in #442. The scan skips the index, its side files and
vaultik.pid, with symlinks in their directories resolved the way source paths are. The lock directory now comes frompidlock, so the CLI and the scanner share one path.Model: opus-5-5