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

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

Aperta
  • Qualcosa non va?
#2,646 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

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

Direzione di ricerca

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.

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

Descrizione

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.
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 6h
PR unite (30g)
201

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

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.