Read Error Recovery for Unsafe Compaction

[zipmagic]

When wimlib is being consumed from Windows PE/RE, sometimes a read error occurs:

WhatsApp Image 2026-02-05 at 21.29.00.jpeg (96.2 KiB) Viewed 9922 times

Which is always fatal during unsafe compaction passes:

WhatsApp Image 2026-02-05 at 00.23.13.jpeg (127.69 KiB) Viewed 9922 times

The thing with these types of failures is, they are almost always intermittent. The above examples were on two different OS instances - both on different sets of hardware (Intel 285HX and AMD 9955HX3D, Phison vs. WD SSD), albeit identical base OS image. While a hardware error cannot be ruled out, it is more than likely a transient failure in Windows and/or the OS image and/or the updates that broke something in it.

I have requested in the past that a workaround be instituted in these scenarious, so as to not render the WIMBoot volume unbootable after this failure. The requests were always turned down, due to the inherent difficulty of reconciling all chunks affected by the read error (it's not just a single file potentially - although the progress report makes it look like it is - instead, it is more often a shared chunk of data that may be in use by countless other files, thanks to built-in data deduplication).

Claude AI to the rescue, then:

wimlib-1.14.5-correct-fix-all-files.zip

(1.13 MiB) Downloaded 277 times

Would it be possible to check whether Claude did a decent enough job here in providing the requested recovery option for us here?

[zipmagic]

Also, here should be just the modified files, assuming Claude AI hasn't hallucinated too badly, of course:

wimlib-1.14.5-correct-fix-modified-files.zip

(111.1 KiB) Downloaded 427 times

I truly hope this would be the healing salve for these kinds of (wishfully formerly) fatal read errors?

[zipmagic]

Been working on this since my last post - it's been more than a month already!

Using fashionable vibe coding, I got it to the point where it'd create a WIM that works, for a given definition of works:

- The WIM file is created and the process doesn't abort
- The WIM file can be extracted using DiskZIP (which is based on 7-Zip), but there's many extraction errors on corrupt files (as expected)
- The WIM file can NOT be extracted - either in literal mode or in WIMBOOT mode - with wimlib

Claude tried to fix the extraction, but hasn't had any luck with it.

I consider it a rarity that it was able to fix compression at all - most Claude sessions failed miserably, despite repeated efforts.

Happy to share the vibe coded sources if there's any interest?

I'm wondering if it may make more sense to just attempt to pre-read files and bail if that doesn't work - although, that still wouldn't help with intermittently surfacing read errors due to underlying hardware issues and whatnot.

If this approach is condoned - what kind of code would make sense for trying reads? After all, WIMLIB is already scanning the drive before compression - what extra thing could we be doing that it doesn't pick up to begin with?

I fortunately have two devices - one physical, the other a VM - where I have two different kinds of stable read errors for testing.

The physical machine has an image I keep re-using from backups as necessary, ditto the VM itself, of course.

[zipmagic]

Got it working!!!