Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#698 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 3 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
backend, operating-systems

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Visual Basic .NET
Estrellas
8.9k
Forks
343
Merge medio
3 d 18 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de IridiumIO/CompactGUI

Todos los issues de IridiumIO/CompactGUI

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.