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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#708 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
76/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp
Lĩnh vực
devtools

Hướng nghiên cứu

Bắt đầu với src/Fallout.Build/Logging.cs, đặc biệt là Logging.Configure, DeleteOldLogFiles và ConfigureFiles. Tái hiện xung đột bằng cách chạy một lượt build dài rồi chạy ./build.cmd --help từ cùng thư mục gốc. Triển khai hành vi được đề xuất là bỏ qua việc cắt ngắn build.log dùng chung và sink khi tệp bị khóa; hoàn tất khi lượt build thứ hai bắt đầu và ghi vào tệp log có dấu thời gian của nó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C#
Star
177
Fork
24
Merge trung bình
4 ngày 17 giờ
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Fallout-build/Fallout

Tất cả issue của Fallout-build/Fallout

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.