File-operation failures can return success and leave the GUI reporting Complete

Start in CompactGUI.Core/Compactor.cs and Uncompactor.cs at the failure-count branches, then follow the caller in CompactGUI/Services/CompressableFolderService.vb to see how its return value affects the GUI. Reproduce the locked-file compression and decompression cases described in the issue and trace the resulting status. Done means failures are surfaced accurately in the operation result and GUI, including the affected file details.

Tested on official v4.0.0-beta.12, Windows 11 25H2 (26200.9711), ASUS Vivobook S 15 / Snapdragon X Elite X1E-78-100 / 16 GB RAM, .NET 10.0.13. Both the native ARM64 application and the official x64 application were tested directly on this ARM laptop. Additional component checks used unchanged libraries extracted from the x64 release, with the release's embedded manifest. No Intel/AMD PC was tested. Only disposable files were used. Most testing was automated with Codex, with human assistance identified where applicable. Related build request: #556.

A failed compression is reported as Complete/Compressed, and a failed decompression does not surface its error. This is related to the diagnostic gap in #551, but the reproduction here specifically demonstrates a success result despite failure.

Compression reproduction

1. Create a compressible 4 MiB file in a disposable folder. Add it to CompactGUI, let analysis finish, and choose LZX.
2. Hold the file open with FileAccess.Read and FileShare.None.
3. Click Compress while the handle is held.
4. Release the handle and independently query the file's WOF state and hash.

Expected: a failure or partial-failure indication identifying the affected file.
Actual: the queue reaches 100% and says Complete; the folder says Compressed, although 0 of 1 files is compressed and no space was saved. The log says:

Compression failed with error: "1 file operation(s) failed."

Reproduced twice at 12:29:02 and 12:29:57 BST on 21 October 2026. Independent queries found WOF mode None and matching SHA-256/length. An unlocked retry compressed the same file to LZX with 24,576 stored bytes and preserved content.

Decompression variant
First compress the unlocked file to LZX, analyse it, then hold the same READ-only exclusive handle and click Uncompress. The log reports one failed operation; the UI returns without a visible error. After the handle is released, the file is still LZX and its hash/length match. Reproduced at 12:39:13.

Read-only access matters: a write-access handle can itself cause Windows to decompress a WOF file, so that is not a valid unchanged-state control.

Source explanation
Both failure-count branches log an error and then return true:

• Compactor.cs lines 84–89
• Uncompactor.cs lines 58–63
• Caller treating the return as success

A structured result or failure return, visible partial-failure status, and retained per-file error details would make the outcome reliable.

x64 component comparison (21 October 2026)

The underlying result-reporting defect also reproduces with the x64 release libraries. Two read-only exclusive-lock compression attempts each returned true, logged the failure below, and left the 4,194,304-byte file uncompressed. Locked decompression likewise returned true and logged a failure, while the file remained LZX with 20,480 stored bytes. Unlocked controls and cleanup succeeded; SHA-256 and length were unchanged throughout.

Compression:   Return=true; Error: Compression failed with error: 1 file operation(s) failed.
              WOF external=0; stored bytes=4,194,304
Decompression: Return=true; Error: Decompression failed with error: 1 file operation(s) failed.
              WOF external=1; provider=2; algorithm=1 (LZX); stored bytes=20,480

The false-success return and misleading GUI outcome were subsequently reproduced in the official x64 application as well, as detailed below.

For an exact read-only lock, run the following in a separate PowerShell session using a disposable file's path, keep it open during the operation, then press Enter to release it:

$testFile = 'C:\DisposableTest\payload.txt' # replace with your test file
$hold = [IO.File]::Open($testFile, [IO.FileMode]::Open, [IO.FileAccess]::Read, [IO.FileShare]::None)
try { Read-Host 'Run the CompactGUI operation, then press Enter' } finally { $hold.Dispose() }

Direct x64 GUI follow-up (21 October 2026, BST)

The same read-only exclusive-lock steps were performed through the actual x64 application's buttons. At 17:50:57.912 it logged one failed compression operation, while the queue reached Complete/100% and the result showed 0 of 1 files compressed. Independent verification found the 4,194,304-byte file still uncompressed with its original hash. An unlocked GUI retry successfully produced LZX with 20,480 stored bytes.

At 17:53:58.262 the locked GUI Uncompress operation logged one failed operation and returned without a visible failure message. The file remained LZX at 20,480 stored bytes. Releasing the lock and retrying Uncompress restored it. SHA-256 and length matched at every checkpoint. This confirms the interface behavior in both builds on Windows ARM64.