File.Replace backup verification strategy for cross‑framework compatibility

Question

The objective is to define a reliable verification workflow for System.IO.File.Replace when a backup is used to restore a file, ensuring byte‑level integrity and preserving metadata across supported .NET versions and file systems.
Key constraints include the fact that File.Replace does not provide a built-in hash, creates a backup copy of the destination, and its behavior changes with ignoreMetadataErrors, NTFS versus non‑NTFS volumes, and locked or read‑only files; hash comparison alone validates only accidental byte changes and cannot guarantee trust in the backup source.
Uncertainty remains about whether to verify the backup before replacement, verify the restored file after replacement, or perform both checks, and how to handle partial failures, alternate data streams, ACLs, and platform‑specific exceptions.
What verification approach best balances safety and performance for File.Replace across .NET Framework, .NET Core/.NET 5+, and non‑NTFS file systems? Should the backup be hashed prior to replace, the destination hashed afterward, or both, and how should locked‑file or metadata errors be managed?

Muntasir · Answer

Recommended Verification Order
Hash the source file before calling File.Replace, then hash the destination file after the call succeeds and compare the two. Do not hash the backup before replacement; it does not exist yet. Hash the backup only after replacement succeeds, and only if you need to validate a future restore.

Confirmed behavior

File.Replace renames the destination to a backup, then renames the source to the destination. On Windows the backup name is deterministic with a generated suffix; on Unix it is a hidden file in the same directory with a .replace_backup prefix.
A locked destination throws IOException before any backup is created, leaving the original destination intact. A locked source throws during the second rename.
ignoreMetadataErrors: true suppresses timestamp and attribute mismatches, but not ACL or alternate-data-stream failures on NTFS. On non-NTFS volumes that metadata is silently dropped.
Read-only source handling differs by runtime: .NET Framework 4.x may throw UnauthorizedAccessException, while .NET Core 3.1+ and .NET 5+ clear the attribute automatically.

Steps for this case

Compute SHA-256 of the source file and store the hash.
Call File.Replace(source, destination, backupName, ignoreMetadataErrors: true).
Compute SHA-256 of the new destination and compare it to the stored source hash. A match confirms byte-level transfer integrity.
Optionally compute SHA-256 of the backup file immediately after step 2 and archive it for restore validation. On Linux or macOS, copy the hidden backup off the volume immediately because the runtime may remove it after success.
Catch IOException, UnauthorizedAccessException, and PlatformNotSupportedException separately. Map sharing violations to retry-or-abort and do not catch generic Exception.

Platform and performance notes
Assumes .NET Framework 4.6.2+, .NET Core 3.1+, or .NET 5+. Hashing doubles read I/O; for files over 1 GB, use a fast checksum such as xxHash64 for the destination check and reserve SHA-256 for the archived backup. On network shares, atomic rename may fall back to copy+delete; compare File.GetLastWriteTimeUtc before and after to detect fallback.

Uncertainty: File.Replace is not crash-transactional, and behavior on ReFS, exFAT, and network shares varies by runtime version. Verify on each target filesystem before production use.

File.Replace backup verification strategy for cross‑framework compatibility

1 answer

Recommended Verification Order

Confirmed behavior

Steps for this case

Platform and performance notes

Your perspective belongs here.

0 question comments