File-operation failures can return success and leave the GUI reporting Complete
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ó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 58/100
Hướng nghiên cứu
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.
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.
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
- Create a compressible 4 MiB file in a disposable folder. Add it to CompactGUI, let analysis finish, and choose LZX.
- Hold the file open with FileAccess.Read and FileShare.None.
- Click Compress while the handle is held.
- 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:
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.
- 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
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- 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.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của IridiumIO/CompactGUI
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
IridiumIO/CompactGUI#699 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
IridiumIO/CompactGUI#697 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
IridiumIO/CompactGUI#696 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
IridiumIO/CompactGUI#680 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
IridiumIO/CompactGUI#700 ·
Maintainer thường phản hồi trong vòng 3 ngày
Tất cả issue của IridiumIO/CompactGUI
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
volcengine/OpenViking#6445 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add string concatenationĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
EnzymeAD/Reactant.jl#3549 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
deepspeedai/DeepSpeed#8884 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
OCIRepository: pick the Helm chart layer automatically when the first layer is a provenance fileĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
fluxcd/source-controller#2198 ·
Maintainer thường phản hồi trong vòng 1 ngày