273-character path: LZX file is misclassified and Uncompress disappears after reloading

Start with WOFHelper.DetectCompression in CompactGUI.Core/WOFHelper.cs and the consuming logic in CompactGUI.Core/Analyser.cs; compare plain and extended path queries and inspect the app.manifest longPathAware setting. Reproduce with a 273-character path under the release manifest, then verify a failed native query is handled distinctly from an uncompressed file. Done when both release GUIs detect the LZX file after reload and retain Uncompress.

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.

Reproduction

1. Create a compressible file whose full absolute path is 273 characters.
2. Add its containing folder, select LZX, and compress.
3. Compare the result pane with an independent WOF query.
4. Clear the completed queue entry and add the same folder again.

Expected: detect the compressed file and retain the Uncompress action.
Actual: compression succeeds, but the results show 0 of 1 files compressed and METHOD X4. The analysis log reports ContainsCompressedFiles: False. After reloading, the folder becomes Awaiting Compression and Uncompress is absent.

This was reproduced twice. Independent measurements confirm LZX and unchanged SHA-256/length. Uncompress immediately after the first compression did work; the obstructive state occurs after reloading. Restoration later succeeded through an analysed parent folder.

A direct comparison on the same compressed file returned:

• Plain 273-character path: WofIsExternalFile HRESULT 0x80070003.
• Extended-path form: HRESULT 0x00000000, external=1, provider=2, algorithm=1 (LZX).

Source explanation
WOFHelper.DetectCompression passes FileInfo.FullName without extended-path handling and ignores the returned HRESULT before interpreting the outputs. Analyser consumes the result as compression state.

Please check the native query result and distinguish a query failure from an uncompressed file.

This is different from the older long-path crash in #345: this build compresses the file successfully, then misclassifies it. No data corruption was observed.

x64 component comparison and manifest finding (21 October 2026)

This also reproduces with the x64 release libraries when the test host uses the actual release manifest:

Absolute path length:                  273 characters
Logical bytes / LZX stored bytes:       4,194,304 / 20,480
Plain WofIsExternalFile HRESULT:        0x80070003
Extended-path HRESULT:                  0x00000000
Extended-path external/provider/algo:   1 / 2 / 1 (LZX)
Fresh Analyser.ContainsCompressedFiles: false
After cleanup:                         external=0; SHA-256 and length unchanged

The embedded manifests extracted from the official ARM64 and x64 executables are identical (SHA-256 97BD6264C5CAF9356DFF15C25858FB9E71ED4B5E070B3C73BE4EFD68808BE35F). In both, longPathAware=true is inside an XML comment, so the app does not opt in through its manifest. See the release app.manifest.

A control run of the same x64 libraries under Microsoft's dotnet.exe host, whose manifest actively enables long paths, returned success for the plain query and detected the compressed file. Repeating with the release manifest restored the failure above. This identifies a relevant host-manifest condition; it is not evidence that x64 handles this correctly while ARM64 does not.

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

At 17:58:40 the official x64 application compressed the 273-character-path file with LZX. Independent verification found external=1, provider=2, algorithm=1 and 20,480 stored bytes, with the original SHA-256 and length. The GUI nevertheless showed 0 of 1 compressed and METHOD X4; analysis reported ContainsCompressedFiles: False. Clearing the completed entry and adding the same folder again at 17:58:54 produced Awaiting Compression with no Uncompress action.

Thus the disappeared action is directly reproduced in both release GUIs, in addition to the component and manifest controls. The test file was subsequently restored with the official Uncompactor and its contents verified. Check both native path handling and the application manifest, and handle a failed native query explicitly.