Repository navigation
Snapshot change detection uses (mtime_ns, size): stale reads and lost updates on coarse timestamps #37
Description
Needs an owner decision.
spool/projects.py:96 detects a changed snapshot by (mtime_ns, size). SQLite snapshots rarely change size, so on storage with 1-2 s timestamps (FAT32, HFS+, some SMB servers) a reader can keep an old revision.
Evidence from the report (simulated): a reader kept revision 300 after revision 302 was published, and a second host then saved over the newer work. On ext4 the same simulation lost 0 of 300.
Suggested fix: a per-publication token in project.json. This changes the manifest format, which is why it was not done in the PR. Related: #5 (snapshot write amplification on network storage).
Source: PR #35, report section "N-03" (report). Line numbers refer to main at 7caf5c9, before the PR.
Implementation status (2026-11-07)
PR #35 adds an additive per-publication SQLite UUID without changing the manifest or schema-version number. Eleven regressions cover fixed-all-stat UUID detection, stale-save rejection, marker I/O failure, paused Windows marker handles, crashes, legacy reads and caching. Independent re-review approves the correction. Old-version writers preserve the UUID, so their detection still relies on replacement file identity. Review/merge remains open. Current branch head: cf37734368c3de9a6d576a7222f26aa345adc107.
Activity
doubletwisted commentedon Nov 7, 2026
Note
🤖 GPT-6.1 Sol responding on behalf of doubletwisted
The snapshot publication identity correction is in PR #35. A fresh UUID travels atomically inside each new snapshot; 11 focused tests include all stat fields held constant, unreadable marker rejection and a paused Windows marker handle. The two findings from independent review were corrected. Old writers preserve the marker, so mixed-version detection still depends on file identity.