fix(io): copy-fallback for atomic writes on cross-device (EXDEV) rename#2696
Merged
Conversation
…evice link Windows encryption-software filter drivers (e.g. 亿赛通/Esafenet) intercept the temp-file -> target rename that the session, branch, config, and desktop .env/title saves use, returning a cross-device link (EXDEV) even within one directory. The save then fails. Add fileutil.ReplaceFile: it renames as before and, only when that fails, copies the temp file's bytes onto the destination (preserving mode) and removes the temp — the path the encryption drivers allow. Route the rename sites through it. The edit/write tools already write in place, so they were never affected.
github-actions
Bot
added
the
v2
SivanCola
added a commit
that referenced
this pull request
Jul 5, 2026
…ename failures ReplaceFile fell back to copyOnto after exhausting its rename retries, regardless of why the rename failed. copyOnto truncates dest in place, so a reader racing the copy observes an empty or half-written file — silently breaking the atomic-publication contract every AtomicWriteFile caller relies on (session leases, credentials, plugin state, mcp.json). CI caught it once the window lined up: TestStateLoadDuringSaveNeverSees TornFile failed on windows-latest with 'unexpected end of JSON input' after a transient dest lock outlived the ~0.7s retry budget and the copy truncated the state file under the reader. Split the failure classes. Transient locks (antivirus, search indexer, a reader without delete sharing) now retry longer — 12 attempts, ~1.5s of backoff — and then surface the rename error; a loud failure beats a silently torn file. The cross-device class (ERROR_NOT_SAME_DEVICE / EXDEV, reported by encryption-software filter drivers even for a same-dir rename, #2696) still takes the copy fallback because rename is structurally impossible there — but now immediately, instead of first sleeping through a retry ladder that cannot succeed, which also cuts ~0.7s of latency from every save on such hosts. The rename seam (renameFile) exists because neither failure class can be provoked portably on a real filesystem; the new tests pin dest integrity plus the surfaced error for the transient class, and the immediate no-retry copy for the cross-device class.
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
1 participant
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.
Closes #2694
What
Make atomic file writes survive Windows encryption-software filter drivers (亿赛通/Esafenet and similar), which reject the temp-file → target
renamewith a cross-device link error (EXDEV) even when both paths are in the same directory.Why
The session save, conversation-branch metadata, config save (
reasonix setup//mcp add//thinking), and the desktop.env/ session-title / display saves all write to a sibling temp file and thenos.Renameit onto the destination. On machines with these drivers that rename fails, so the save fails.Note on #2694: the report's
/apply"edit blocks" trace is from the v1 (Node) line — itsEXDEV: ... renamestring andwrite-file-atomictemp names are libuv's. In v2 thewrite_file/edit_file/multi_edittools already write in place (os.WriteFile), so the edit path was never affected. The same failure mode does exist in v2's rename-based atomic saves, which this fixes.How
New
fileutil.ReplaceFile(tmp, dest): renames as before, and only if the rename fails, copies the temp file's bytes onto the destination (re-applying the temp's mode so a0600config temp doesn't widen) and removes the temp — the copy path the drivers permit. The original rename error is surfaced only if the copy fallback also fails, so genuine failures aren't masked. Routed the five rename sites (agent/save.go,agent/branch.go,config/edit.go,desktop/dotenv.go,desktop/sessions.go) through it.codegraph/install.goalso renames, but that's a directory move during install (a different, recursive case) and out of scope here.Tests
internal/fileutilunit tests cover the rename happy path and the copy fallback (full overwrite of a longer destination + temp removal + mode). Runs on all three OS legs including windows-latest. Desktop module builds and its session tests pass.