Fixing WOF Errors (catch 22)

[Maingron]

So in the past I used CompactGUI on top of the standard NTFS compression. I'm now on a different system, trying to copy files from the old HDDs to a new storage pool.
Unfortunately, I get Errors like Error code 0x1160: The WOF driver encountered a corruption in the compressed file's Resource Table. [CopyFileEx] or Error 0x80071160: The WOF driver encountered a corruption in the compressed file's Resource Table.
I'm wondering on how to fix this. Searching online I only get results for such problems regarding Windows Update.

I'm pretty certain the files are technically still intact, as I never had any problems using them before - I'd have noticed, since it affects most of my VM HDD images.
I suspect it worked before, since the files were properly watched, in the right order, basically.

I tried to run some experiments on these files already. I managed to remove the standard NTFS compression through explorer, I seemingly can't reverse this process, however.

Since I ran a RAID 1 before, I still have one copy of those files in their original state.

Can anyone help me find a solution to this, please? Would recovering any specific system- or config files from the original computer help in this situation?
As stated before, I'm certain the files are intact and worked on the old PC. It seems more like a catch 22 in this case, where each layer depends on the other first

[Maingron]

I forgot to mention that I'm also using VeraCrypt.

So the topology should originally have looked like this:

HBA(Raid1) <- HDD <- VeraCrypt <- NTFS <- NTFS & CompactGUI compression

Right now I'm cutting the HBA in the line and instead connect only one HDD via USB, although this shouldn't make a difference. Of course I'm also on a different system with a fresher installation of Windows 11.

Most files didn't cause problems, only the ones compressed with CompactGUI. I can't really remember which files I had compressed using this strategy, but I'm certain the only files causing problems have been compacted using this strategy. I believe it's not affecting ALL files that have been compacted like this, however.

Looking at one VM directory, for example, shows that the older VMDKs are inaccessible, while Log files were created at a later point, and are still accessible. While I'm not sure if said Log files were ever touched by CompactGUI at this later date, it definitely shows that the VMs had been used after compacting.

[Iridium-IO]

Hmm I'm not certain but I'd imagine what you've got is the compressed files created by CompactGUI (which uses the underlying Windows WOF driver, nothing more) are running into either of two issues:

Most likely (I think) is that the compressed shadow files are split across the entire RAID array and so you'd need to either plug in both drives at once or uncompress the files before moving them. You could shortcut this by opening the root drive in the command prompt and typing compact /u /exe /s which will find every WOF compressed file on the drives and uncompressed them.

The other possibility is to do with Veracrypt. I've never used it, but if it's at a drive level then maybe the encryption needs to be disabled first, in order for the shadow files to be accessed?

[Maingron]

@Iridium-IO to me, VeraCrypt is basically a container for the entire filesystem, pretty much like LUKS. You unlock VeraCrypt and you get a mounted NTFS drive.

The files shouldn't be split either, since the Raid 1 happened at a hardware level, and each month, starting on the 20th, I was bothered by slow I/O due to consistency checks, which I'm not aware of any mismatch ever occurring. So every bit on one drive was exactly identical to the bits on the other drive.
As far as VeraCrypt is aware: The HBA exposed the HDDs in Raid 1 as a single drive to the System, so VeraCrypt took this "one" drive and encrypted it, exposing a "fresh" HDD, while un-exposing the raw drive. I guess you can think of it like a mounted VHD. And at this point you can format the "VHD" with NTFS, for example, starting the relevant logical chain in our case. This rules out shadow files being split, or inaccessible due to VeraCrypt (I've configured the VeraCrypt encryption on the drive before formatting with NTFS, and never changed the encryption, so it's impossible shadow files leaked through VC)

I have since tried fetching the files using the original OS installation, but still with only 1 HDD plugged into Sata instead of the HBA, but I didn't have luck this way either. Unfortunately I can't really verify with both drives anymore since 1 drive is now dirty and the HBA wouldn't deal with this well.

I didn't have time to deal with this yet, but on my backup drive I found working versions of the files (uncompressed, however). This will mostly resolve my problem of not having access to the files at all, unless I'll encounter a file that's not on the backup drive, but I'm still certain this problem occurred on a software level, at or after the compression layer. Since it only affects some files that have been compressed, it's unlikely to have been caused by the Raid configuration or VeraCrypt.

I may try checking what happens when decrypting the drive, after I've deleted the rest of the files, but since this happens before the NTFS layer, I suspect that'd do exactly nothing, but removing the encryption layer before NTFS, not changing anything within NTFS, thus the files would still be inaccessible.

The idea of basically listing the broken files by running compact /u /exe /s is great tho and certainly will help me in moving the files to my NAS! I'll just do 2 batches, one excluding any broken file, and one extracting the broken files from the backup drive.