Restored VB.NET Files via My.Computer.FileSystem: Integrity Still Unresolved

Answer

Verified recovery should first be confirmed by byte‑level hash equality (e.g., SHA‑256) between the original backup and the file restored by My.Computer.FileSystem.CopyFile or CopyDirectory. A matching hash proves storage‑level integrity; any difference indicates corruption or alteration.

If the hashes match, the next confidence layer is successful parsing by the target application (or a dedicated validation routine). Parsing shows the file is usable in its intended context, but it does not guarantee bit‑for‑bit fidelity.

Manifest record‑count agreement can catch truncation or missing records, yet it is the weakest signal because it ignores value‑level changes and encoding effects.

Steps to verify

1. Compute a SHA‑256 hash of the backup file (System.Security.Cryptography.SHA256).
2. Compute the same hash of the file produced by My.Computer.FileSystem.CopyFile (or the corresponding file inside a copied directory).
3. Compare the two hex strings; if they differ, recovery is not verified – investigate the backup or copy process.
4. If the hashes match, attempt to load the restored file with the application’s native parser (e.g., XmlDocument.Load, DataSet.ReadXml, or a custom business‑object reader). Record any exceptions or validation failures.
5. For text‑based files, read the restored file with System.IO.StreamReader using the exact Encoding that was used when the backup was created (e.g., Encoding.UTF8). Optionally recompute the hash on the decoded byte sequence to confirm encoding consistency.
6. If a manifest exists, compare the expected record count with the actual count obtained after parsing; a mismatch points to truncation.

When signals disagree

• Hash matches, parsing fails: Treat the hash as authoritative for storage integrity; the failure likely stems from a format‑specific issue (wrong encoding, version‑specific schema, or application‑tolerated transformation). Investigate the parser or the backup’s logical content.
• Hash differs, parsing succeeds: The backup snapshot was already altered or the copy process transformed the data in a way the application tolerates (e.g., line‑ending normalization). Consider the backup corrupt or treat the restored file as a new version; re‑create the backup from a trusted source.
• Hash matches, manifest count mismatches: Indicates truncation or missing records that still hash to the same value (unlikely with a strong hash) – re‑check the hash implementation; otherwise, treat the hash as correct and investigate why the manifest does not reflect the actual content.

Specifying encoding to avoid silent reinterpretation

Always pass the explicit Encoding object to any read/write operation that deals with text. When using My.Computer.FileSystem prefer the overloads that accept an Encoding parameter, for example:

Dim backupText As String = My.Computer.FileSystem.ReadAllText(
    backupPath, Encoding.UTF8)

My.Computer.FileSystem.WriteAllText(
    restorePath, backupText, False, Encoding.UTF8)

If the original encoding is unknown, determine it by examining the backup file (e.g., using a binary editor to look for a BOM) or by consulting the process that created the backup. Supplying the correct encoding prevents silent character reinterpretation that would not raise an exception.

Missing diagnostic detail: What exact encoding was used when the backup was created? Knowing this is required to choose the correct Encoding argument in the steps above.