Skip to content

fix: capture SQLite backups without modifying original databases - #16

Merged
santoshkumarradha merged 1 commit into
mainfrom
fix/nonmutating-sqlite-capture
Oct 26, 2026
Merged

santoshkumarradha merged 1 commit into
mainfrom
fix/nonmutating-sqlite-capture

Conversation

@santoshkumarradha

Copy link
Copy Markdown
Member

Ordinary capture opened original SQLite databases through SQLite's read-only API, which can still create or change WAL shared-memory files. A closed WAL-mode database could therefore gain sidecars during capture and make a subsequent fork refuse its own source changes.

Capture now reconstructs a private database family from verified captured blobs before SQLite opens it, reusing the scoped-capture path. Guarded staging refuses symlink sidecars and verifies regular-file identity. The source database is never opened through SQLite. This preserves the quiescent-source contract; it does not promise an atomic snapshot of independently changing files.

Public CLI regressions verify unchanged closed-WAL source bytes, unchanged committed WAL families with a coherent private SQLite restore, and refusal of existing/dangling symlink sidecars without changing their targets. Prepares version 0.3.2; 0.3.1 remains unchanged.

Validation: cargo fmt --all -- --check; cargo clippy --workspace --all-targets --locked -j 4 -- -D warnings; cargo test --workspace --locked -j 4.

@santoshkumarradha
santoshkumarradha merged commit ce0064c into main Oct 26, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant