From: nospam@needed.invalid   
      
   On Mon, 2/16/2026 3:30 PM, Lawrence D’Oliveiro wrote:   
   > On Mon, 16 Feb 2026 03:33:37 -0500, Paul wrote:   
   >   
   >> And the .mrimg has some kind of primitive repair capability (implying   
   >> hashes at some level) ...   
   >   
   > You need a bit more than hashes to do “repair capability”. That means   
   > error *correction*, not just *detection*.   
   >   
   > For example, optical media make heavy use of Reed-Solomon   
   > Cross-Interleave Redundancy Checking, applied at two separate levels:   
   > one as an error-correction code and the other as an erasure code. As I   
   > recall, on DVD, this redundancy overhead reduces the effective storage   
   > capacity by about half.   
   >   
      
   The product did not always have repair capability.   
      
   https://knowledgebase.macrium.com/display/KNOW80/Understanding+I   
   age+Verification+Failures   
      
      "When an image is created each block of data (generally 64K but may be   
   larger depending   
       on the partition size) has an MD5 hash digest created after it is read   
   from the disk   
       and before it is written to the image file. This hash value is saved in   
   the index   
       of the image file."   
      
   From the PDF manual, (V8 Page 177 printed at bottom of page)   
      
      "Backup verification checks the entire contents of backup files against MD5   
   message   
       digests (Hashes) created from the source data when the backup was created."   
      
      "If corruption is detected in a backed up data block then the current   
       live file system is checked to see if it contains the original data.   
       ...   
       Note: Verification will halt on the first un-repairable block detected."   
      
   So it's a weak sauce. It repairs if it works out that the original   
   file is present and within reach. It has the disk identifiers from   
   when the disk was backed up, to use as part of comparison. You would   
   want to be running Verify then, first, rather than erasing the   
   source drive and trying to restore over top.   
      
   Repair then, is via "duplication", it relies on the original   
   disk to be around, and if a file hasn't changed, it can "save"   
   the session from being trashed. If you were overwriting the   
   original disk at the time, then that would have erased any chance   
   of doing a repair to the file.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)