Ability to delete log files and recreate them immediately

[thiagosgarcia]

As discussed in #96 and #128, this gives the ability to delete files when is created by a SharedFileSink and recreates the rolling file when deleted.

This is my implementation for #144. Took me a while to be able to do some house cleaning and resume pending projects.
Also validated in runtime through the sample projects on linux-x64 and win-x64.

[Copilot]

Pull request overview

This PR addresses issues #96 and #128 by allowing log files opened via shared: true to be deleted at runtime, and ensuring the sink recreates the current log file immediately after deletion so logging continues without waiting for a roll interval boundary.

Changes:

• Add FileShare.Delete to shared file sinks so log files can be deleted while the process is running.
• Reopen/recreate shared log output streams when the underlying log file path has been deleted.
• Add/extend tests covering deletion + immediate recreation behavior (including encoding preservation), and add a new sample project.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/Serilog.Sinks.File/Sinks/File/SharedFileSink.OSMutex.cs	Enables delete-sharing and adds stream reopen logic when the file is deleted.
src/Serilog.Sinks.File/Sinks/File/SharedFileSink.AtomicAppend.cs	Enables delete-sharing and attempts to recreate the file on deletion for the atomic-append variant.
test/Serilog.Sinks.File.Tests/SharedFileSinkTests.cs	Adds tests for delete + recreate behavior (including encoding) for shared sink.
test/Serilog.Sinks.File.Tests/RollingFileSinkTests.cs	Adds tests validating rolling file recreation/deletion behavior when shared: true.
test/Serilog.Sinks.File.Tests/FileSinkTests.cs	Adds a test verifying file recreation after deletion when creating a new FileSink.
serilog-sinks-file.sln	Adds the new Sample-SharedFile example project to the solution.
example/Sample-SharedFile/Sample-SharedFile.csproj	Introduces a new sample project (multi-targeting).
example/Sample-SharedFile/Program.cs	Adds a sample program demonstrating shared-file logging.

Comments suppressed due to low confidence (1)

src/Serilog.Sinks.File/Sinks/File/SharedFileSink.AtomicAppend.cs:133

• When reopening the atomic-append stream after deletion, the FileStream is created with bufferSize: length and _fileStreamBufferLength is set to length. length can be very small (or even 0 if the formatter writes nothing), which can cause ArgumentOutOfRangeException and also shrinks the buffer unexpectedly. Reopen using the existing _fileStreamBufferLength (and avoid decreasing it) when the goal is just to recreate the deleted file.

                    if (!System.IO.File.Exists(_path))
                    {
                        var oldOutput = _fileOutput;

                        _fileOutput = new FileStream(
                            _path,
                            FileMode.Append,
                            FileSystemRights.AppendData,
                            FileShare.ReadWrite | FileShare.Delete,
                        length,
                        FileOptions.None);
                    _fileStreamBufferLength = length;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[nblumhardt]

Thanks for the effort on this!

A File.Exists() call per event has the potential to regress performance; it's also the kind of thing that might have different performance characteristics on different filesystems. It'd be great to dig further into this, and consider what kinds of alternatives might be available.

[thiagosgarcia]

Understood sir, I'll take to closer look at this.
Indeed, I have ran the test application in a wsl instance and performance wasn't great but I assumed it was the wsl system. I've just setup a Ubuntu box that I'll take advantage and try this in spare time. I will also look for alternatives for this.