Repository navigation
fix(adopt): never let a same-millisecond backup overwrite an earlier one - #3
Merged
Merged
Conversation
backup_to named the backup directory after the current millisecond and the file inside after the flattened real path. Two adoptions of the same file within one millisecond therefore wrote to the exact same backup path. The second backup already contains our gateway key, so it replaced the first backup holding the user's original key. The sidecar still pointed at that path, so restore recovered our key instead of the user's and their original secret was gone. This is what made re_adopting_does_not_overwrite_what_the_original_was flaky (~1 in 3 local runs), but the data loss is real, not just a test artefact. Directories are now named `<ms>-<seq:04>` and claimed with create_dir (not create_dir_all), bumping seq on AlreadyExists, so the filesystem decides atomically who gets a name. The file inside is opened with create_new so an existing backup is never overwritten. Zero-padding keeps "sort by name = chronological order"; old plain `<ms>` directories sort before any `<ms>-NNNN`, and nothing parses the names as integers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fylorn
added a commit
that referenced
this pull request
Sep 14, 2026
…one (#3) backup_to named the backup directory after the current millisecond and the file inside after the flattened real path. Two adoptions of the same file within one millisecond therefore wrote to the exact same backup path. The second backup already contains our gateway key, so it replaced the first backup holding the user's original key. The sidecar still pointed at that path, so restore recovered our key instead of the user's and their original secret was gone. This is what made re_adopting_does_not_overwrite_what_the_original_was flaky (~1 in 3 local runs), but the data loss is real, not just a test artefact. Directories are now named `<ms>-<seq:04>` and claimed with create_dir (not create_dir_all), bumping seq on AlreadyExists, so the filesystem decides atomically who gets a name. The file inside is opened with create_new so an existing backup is never overwritten. Zero-padding keeps "sort by name = chronological order"; old plain `<ms>` directories sort before any `<ms>-NNNN`, and nothing parses the names as integers. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
re_adopting_does_not_overwrite_what_the_original_wasincrates/tw-adopt/tests/roundtrip.rsis flaky: 10 of 30 local runs failed on unmodifieddev(6ac917c), and it failed CI on #2, which only touched Cargo.toml descriptions.It is not a test problem.
backup_toincrates/tw-adopt/src/foreign.rsput backups atbackups/<now_ms>/<flattened real path>. When the same file is adopted twice within one millisecond:sk-ant-…, their own key) tobackups/<ms>/….tw-…key — to the same path, overwriting step 1.plan_restore/apply_restorerecover the secret original from the overwritten backup and restore the user's config with our key. Their original key is lost.The fix
<ms>-<seq:04>and claimed withstd::fs::create_dir(notcreate_dir_all); onAlreadyExiststhe sequence number is bumped. The filesystem decides atomically, so concurrent or back-to-back backups can't share a directory.create_new(true): an existing backup is never overwritten, we fail instead.backup_root— sorting directory names gives chronological order — still holds: the sequence is zero-padded, and legacy<ms>directories sort before<ms>-NNNN.Tests
two_backups_in_the_same_millisecond_do_not_overwrite_each_other: pins two backups of the same file to the same timestamp (via a newbackup_atthat takesms), asserts both exist with their own contents, and that name order is chronological across milliseconds.back_to_back_real_backups_all_survive: 50 backups on the real clock, all intact.cargo test -p tw-adopt --test roundtrip re_adopting_does_not_overwrite_what_the_original_was× 100: 0 failures.cargo fmt --check,cargo clippy --workspace --all-targets -D warnings,cargo test --workspace: all pass.🤖 Generated with Claude Code