cf6196d525a8f69effcaf1507b2b04d0ba065c97
Root cause of the F.13.13 'Budget & cash-flow tracking -> tracker' false-archive incident (2026-09-24): watchdog's inotify cookie-pairing failed on a PLAIN, unloaded, single-folder Obsidian rename -- no burst, no stress test, just an ordinary rename -- producing a bare on_deleted and a bare on_created ~12s apart instead of one on_moved. This is the same underlying gap as the earlier Untitled-placeholder bug, but proves it is not just a high-load phenomenon: any rename can split this way. Fix: handle_vault_deleted no longer archives an ID-folder deletion immediately. It holds the delete in _pending_id_deletes, keyed by the JD ID code (title-independent, e.g. "F.13.13"), for RENAME_GRACE_SECONDS (15s). handle_vault_created checks this dict on every create; if a create for the SAME ID code lands within the window, _resolve_as_rename moves /data's old-named folder to the new name (and renames its folder-note file to match) instead of archiving -- recovering the rename watchdog failed to pair. If nothing claims the pending delete within the window, _finalize_pending_delete archives it exactly as before (real deletions are unaffected). Tested live both ways: (1) delete+create with same ID within the window -> recovered as a rename, test file content preserved, no archive slot created; (2) delete with no matching create -> correctly archived after the grace window expires, same as pre-fix behavior.
Description
vault CLI + Librarian tooling for Ryans R/J/F/I Obsidian vault
262 KiB
Languages
Python
96.4%
Nix
2.3%
Shell
1.3%