Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#698 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
backend, operating-systems

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Visual Basic .NET
Stelle
8.9k
Fork
343
Merge medio
3g 18h
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di IridiumIO/CompactGUI

Tutte le issue di IridiumIO/CompactGUI

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.