C#: store replace on Windows tries POSIX-semantics rename first (store-windows-cs) #152
2026-11-12
StoreReplace: unresolved kernel32 imports degrade, claims say rare not never, killing tests
All checks were successful
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Successful in 22m32s
ReplaceWindows owns the unresolved-import decision: a POSIX call that does not resolve (DllNotFound/EntryPointNotFound) is "unsupported"; a MoveFileExW that does not resolve degrades to the portable File.Replace/Move. Tests for each exception type, the last-attempt same-attempt fallback and the retried-87 case. Doc and Mesh test comments no longer claim a reader never finds the path absent; the Mesh race test tolerates a brief not-found on Windows. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
StoreReplaceTests: the exhaustion message names the last code, not just "Win32"
Some checks failed
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Has been cancelled
Mutation survivor: Contains("32") matched "Win32".
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
StoreReplace: POSIX-first Windows replace for the single-file and directory stores
Both store writers call StoreReplace.Replace; the directory store's File.Replace retry loop and WriteSnapshotAtomically's Exists/Replace/Move block are deleted. Un-ignores the mesh empty-store race test on Windows. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
StoreReplaceTests: the Windows replace decision table through a fake kernel (red)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>