Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#698 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
csharp
領域
backend, operating-systems

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Visual Basic .NET
スター
8.9k
フォーク
343
平均マージ
3日 18時間
マージ済み PR（30日）
7

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

IridiumIO/CompactGUI のほかの issue

IridiumIO/CompactGUI の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。