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

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#708 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 5 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp
Área
devtools

Línea de trabajo

Empieza por src/Fallout.Build/Logging.cs, especialmente por Logging.Configure, DeleteOldLogFiles y ConfigureFiles. Reproduce el conflicto ejecutando una compilación larga y luego ./build.cmd --help desde la misma raíz. Implementa el comportamiento propuesto de omitir el truncamiento de build.log compartido y el sink cuando esté bloqueado; estará listo cuando la segunda compilación se inicie y escriba en su archivo de registro con marca de tiempo.

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

Descripción

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.

Lenguaje dominante
C#
Estrellas
164
Forks
19
Merge medio
3 d 7 h
PR fusionados (30 d)
9

Preparar el entorno

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

Todos los issues de Fallout-build/Fallout

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.