Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#695 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
56/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
backend, desktop

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Visual Basic .NET
Star
8.9k
Fork
343
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của IridiumIO/CompactGUI

Tất cả issue của IridiumIO/CompactGUI

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.