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

A second build in the same root fails because build.log is locked by the first

Aperta Adatta ai principianti
  • Qualcosa non va?
#708 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 5 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
devtools

Direzione di ricerca

Inizia da src/Fallout.Build/Logging.cs, in particolare da Logging.Configure, DeleteOldLogFiles e ConfigureFiles. Riproduci il conflitto eseguendo una build lunga e poi ./build.cmd --help dalla stessa root. Implementa il comportamento proposto di saltare il troncamento del build.log condiviso e il sink quando è bloccato; il lavoro è completato quando la seconda build si avvia e scrive nel proprio file di log con timestamp.

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

Descrizione

Version: Fallout.Common 10.4.0, Windows 11, .NET SDK 10.0.112

What happens: while one build runs (for example a long-running target), starting a second build in the same root directory fails at startup with:

The process cannot access the file '<root>\.fallout\temp\build.log' because it is being used by another process.

Why: Logging.Configure calls DeleteOldLogFiles, which truncates build.log with File.OpenWrite, and ConfigureFiles opens build.log through a non-shared Serilog file sink. The first build holds that file for its whole run, so both steps fail in the second (Logging.cs). NUKE behaves the same.

Repro: start ./build.cmd SomeLongTarget, then run ./build.cmd --help in the same directory while the first is still running.

Expected: the second build runs. Each run already writes its own build.<timestamp>.log, so only the shared build.log stands in the way.

Possible fixes:

  1. When build.log is in use, skip truncating it and skip the build.log sink, so that run logs only to its timestamped file. This is the smallest change, and build.log keeps meaning "the log of the run that owns it".
  2. Open build.log with shared: true, and truncate it only when nothing else holds it. Runs then interleave in one file.

Either way, the timestamped name has one-second resolution, so two runs started in the same second also collide. Adding milliseconds or the process ID would avoid that.

We would like to contribute option 1 if it's acceptable.

Current develop still contains the shared build.log truncation and non-shared sink as inspected on 12 October 2026. We found no matching existing report in the issue search. This report concerns logging; our separate bootstrap copies the build executable per invocation to avoid output-binary locks.

Lingua principale
C#
Stelle
164
Fork
19
Merge medio
3g 7h
PR unite (30g)
9

Preparare l'ambiente

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 Fallout-build/Fallout

Tutte le issue di Fallout-build/Fallout

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.