Atomic writes

Writes and edits replace the destination with temp file plus rename, on every platform. A crash during the write leaves the previous file in place.

NTFS file id, birthtime, and hardlinks do not survive. The path points at a new file. A hard link to the old file keeps the old bytes and the old id. This is the same tradeoff the reference server kept on Windows. TestWriteAndEdit_TempRenameDropsNTFSIdentity locks that behavior.

On Windows, os.Rename can fail with ERROR_ACCESS_DENIED while a scanner or indexer holds the destination. renameWithRetry retries at 50, 100, 200, and 400 ms.

write_file reopens the final host file after the rename. Structured output sets verified only when that reopen succeeded. bytes_written and content_hash come from those bytes, not from the request size. If verification fails, the text says the atomic write returned success but the host file could not be reopened. Confirm with get_file_info or read_file. Do not repeat the write blindly.

batch_operations writes use the same temp-plus-rename helper. atomic:true is an in-process journal (complete, partial, or failed). It is not crash-durable. create_dir is rejected in an atomic batch because the journal snapshots regular files, not directory trees.

apply_patch on several files is also an in-process transaction: validate all, then write, journal rollback if a commit fails. It is not crash-durable. It does not create directories. The destination directory must exist.