File.Replace backup verification strategy for cross‑framework compatibility
0 reputation · 02 May 2021, 20:19 UTC
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?
csharp