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

Windows: a file named `nul` in the repo makes every index_repository abort with aborted_previous_preserved (0.11.0)

Abierto
  • ¿Algo no está bien?
#2,646 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Start with semantic_manifest_hash_file in src/pipeline/pipeline_incremental.c (around line 168), where a non-regular path returns CBM_NOT_FOUND, and the loop around lines 512-515 that aborts the whole manifest on one failure. Reproduce on Windows by creating an empty nul file in a small repo and running index_repository, then check the path handling. Done means the index completes with the reserved-name file skipped, or the response names the offending path instead of the generic hint.

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

Descripción

bug parsing/quality priority/high stability/performance windows
Environment
  • codebase-memory-mcp 0.11.0 (Windows 11, x64), daemon build 7edcd3807ebc…
  • Repository on NTFS, plain git checkout
What happens

A single empty file literally named nul in the repository root makes every index_repository run on that repository abort within ~3 s:

{"project":"<name>","status":"aborted_previous_preserved","hint":"Indexing aborted before publication; the previous index is intact and still serving. Causes: files changed while the run was in flight, or a discovery/manifest phase failed transiently. Retry; if it repeats, check the run log."}

It repeats on every retry (--mode full and --mode fast), so for an unindexed project no index is ever created. No run log survives (the worker log is unlinked on clean exit), so the only visible signal is the generic hint above, which points at "files changed" / "transient" causes rather than a deterministic one.

Such files are common on Windows: a shell command written as cmd > nul or 2>nul and run under Git Bash/MSYS creates a real file named nul. On Win32, opening <dir>\nul without the \\?\ prefix opens the NUL device, not that file.

The file was also listed in the repository's .gitignore (nul), and the run still aborted.

Reproduction
  1. Take any small git repository that indexes successfully.
  2. Create an empty file named nul in it (from Python: open(r"\\?\C:\path\to\repo\nul", "wb").close()).
  3. Optionally add nul to .gitignore.
  4. codebase-memory-mcp cli index_repository --repo-path C:\path\to\repo → aborted_previous_preserved.
  5. Delete the file (os.remove(r"\\?\C:\path\to\repo\nul")) → the same command returns indexed.

I verified this by bisection: a copy of the affected repository's git-visible files indexed fine; adding only an empty nul reproduced the abort; removing nul from the original repository fixed it.

Likely code path (tag v0.11.0, commit 8972ea6)
  • src/pipeline/pipeline_incremental.c:168 (semantic_manifest_hash_file): if (cbm_path_info_utf8(abs_path, &before) != 0 || !before.is_regular || before.is_symlink) { return CBM_NOT_FOUND; } — …\nul resolves to the device, so it is not a regular file.
  • src/pipeline/pipeline_incremental.c:512-515: any per-file failure ends the whole manifest: cbm_log_error("semantic_manifest.err", "path", files[i].path); rc = CBM_NOT_FOUND; break;
  • src/pipeline/pipeline.c:2740-2741: a failed baseline manifest becomes rc = CBM_PIPELINE_ABORT_PRESERVE_DB, reported as aborted_previous_preserved (src/mcp/mcp.c:11266).

I did not confirm from a log which of these lines fired, since the worker log is not kept; the bisection result is the hard evidence.

Expected
  • Discovery skips (or reports as not indexed) Windows reserved device names (nul, con, aux, prn, com1–com9, lpt1–lpt9, with or without extension), and honours .gitignore for them, so one junk file cannot block a whole repository.
  • If a file still cannot be hashed, the response names the path (the semantic_manifest.err path is already logged internally) instead of the generic "files changed / transient" hint.
Lenguaje dominante
C
Estrellas
45.8k
Forks
3.8k
Merge medio
3 d 6 h
PR fusionados (30 d)
201

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 DeusData/codebase-memory-mcp

Todos los issues de DeusData/codebase-memory-mcp

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.