Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#694 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend, desktop

Research direction

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.

Written by the indexing model from the issue text.

Description

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:

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.

Dominant language
Visual Basic .NET
Stars
8.9k
Forks
343
Avg merge
3d 18h
Merged PRs (30d)
7

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IridiumIO/CompactGUI

All issues in IridiumIO/CompactGUI

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.