Rust: store replace on Windows tries POSIX-semantics rename first (store-windows-rs) #148
2026-11-13
cultcache-rs: the replace doc says absence to a lock-free reader is rare on NTFS, not impossible
All checks were successful
CultMesh portability and performance / ubuntu-latest reactive semantics and leases (pull_request) Successful in 22m14s
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: the Windows parent-sync comment no longer credits MoveFileExW alone with durability
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: revert the absolute() destination (a relative FileName works with a null RootDirectory); a delete-sharing reader test discriminates POSIX rename; doc names the ruling and where the table has landed
Soul's Starfire probe (build 26200) showed a relative FileName already works, so the reverted claim was false. windows_replace_tests are compile-checked only and have never run on Windows. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: the POSIX rename passes an absolute destination (FileName without RootDirectory must be a full path)
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: import FILE_RENAME_FLAG_* from Win32::System::WindowsProgramming, where windows-sys 0.59 defines them
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
cultcache-rs: Windows store replace tries a POSIX-semantics rename first through a ReplaceKernel seam
replace_with owns the decision table (POSIX first; 1/50/87 fall back to MoveFileExW write-through for the rest of the call; 5/32/33 retry 25 x 20 ms; else error), tested with a fake kernel on every OS. WindowsKernel holds only the two syscalls. The inline MoveFileExW loop is deleted. (variants:ruling:windows-replace-posix-first) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>