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

Decompressing two hard links logs a failed operation although both names are restored

Open
  • Is something wrong?
#698 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, operating-systems

Research direction

Read CompressableFolderService.vb lines 32–38 and Uncompactor.cs lines 71–89, then trace how both hard-link paths reach FSCTL_DELETE_EXTERNAL_BACKING. Reproduce with a two-name hard-link pair and one worker; check whether the second operation sees the file already restored. Done means decompression restores both names without logging a failed operation.

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.

Reproduction

  1. Create a disposable compressible file and a second hard-link name for it in the same folder. The recorded test used original.txt and alias.txt, 2,150,000 bytes each.
  2. Compress the folder with LZX and one worker.
  3. Click Uncompress.

At 12:43:48 BST on 21 October 2026, the app logged decompression of 2 files followed by "1 file operation(s) failed." Independent checks found both names uncompressed, their hashes/lengths unchanged, and the hard-link relationship intact. The isolated pair reproduced the error seen in an earlier combined-corpus run.

Expected: successful restoration should not generate a misleading failure count for an alias already restored through the other name.

The initial ARM64 run retained only the aggregate error. A follow-up x64 probe below directly supports duplicate processing of the same underlying file as the mechanism.

Relevant source: file enumeration and per-path decompression. Deduplicating by file identity or handling an already-restored file may help.

Related #568 concerns optional creation of hard links. This report concerns handling hard links that already exist; it does not request deduplication or merging user files. No data loss was observed.

x64 component comparison (21 October 2026)

An isolated hard-link pair reproduced the same result twice with the actual x64 core libraries and one worker:

Starting decompression of 2 files with 1 threads
Decompression failed with error: 1 file operation(s) failed.
RunAsync returned: true

Both names before: length=2,150,000; stored=12,288; WOF external=1, provider=2, algorithm=1
Both names after:  length=2,150,000; stored=2,150,000; WOF external=0
Both SHA-256 values before/after:
60BDC2A7EDE27A9A71C6C61012F210544B31F82486D70310AED7B1C7B2BB115A

fsutil hardlink list still listed both original.txt and alias.txt afterward. This establishes the spurious failure result in both builds on this ARM laptop; native Intel/AMD hardware has not been tested. The component checks were followed by a direct x64 GUI reproduction.

Native-error follow-up

After compressing the disposable pair, the official x64 Uncompactor was run on original.txt alone. It succeeded, and independent WOF queries immediately found both original.txt and alias.txt uncompressed. Issuing the same FSCTL_DELETE_EXTERNAL_BACKING operation on alias.txt then returned:

DeviceIoControl success: false
Win32 error: 342
Message: This object is not externally backed by any provider.

Both names still had their original SHA-256 and length. This isolates the redundant second operation as a reproducible source of the failure. Error 342 was captured in this follow-up native probe, not extracted retrospectively from the original GUI log. Checking file identity or treating this already-restored state appropriately would avoid the misleading count.

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

The official x64 application compressed the isolated pair with LZX and one worker. Clicking Uncompress at 18:02:56.413 logged the same one-operation failure for the two-file list. Independent checks again found both names restored, with their original SHA-256 and length and the hard-link relationship intact. This GUI result agrees with both the ARM64 run and the separate x64 native-error probe; the GUI log itself still contains only the aggregate error.

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.