RollingFileSink does not recover from disconnected/lost location access

[grimchamp]

Description
After losing access to a logging directory and regaining access, sink does not resume writing to log file. Internal error is consistently thrown.

Reproduction

1. Create an empty .NET Windows Service
2. Clear logging providers to de-clunk console logging.
3. Implement serilog and rolling file sink (see bottom for config used)
4. Map folder on local machine to L: (example C:\logs)
5. Configure sink to write to L:\logs.txt
6. Start App
7. Disconnect L: mapping after logging started and confirmed in log file
8. Confirm error message logged to console (INF level)
9. Re-map L:
10. Check log file - writing has no resumed
11. Check console window - error still being logged

Expected behavior
Upon reconnection of directory, serilog to reconnect and continue writing. Do not expect buffering of messages during disconnect (perhaps a new buffered file sink could be looked at for this with a FIFO queue internally).

Relevant package, tooling and runtime versions
.NET8 Windows Service project
Serilog.Sinks.File 7.0
Serilog 4.3.0

Note: Issue first encountered on Serilog.Sinks.File version 6.0 and Serilog version 4.0.2. Upgraded to ensure still occurring.

Additional context

Error thrown to console on local machine:

[16:10:12 INF] [30] Worker running at: 08/28/2025 16:10:12 +01:00
2025-08-28T15:10:13.1284647Z Caught exception while emitting to sink Serilog.Sinks.File.RollingFileSink: System.IO.IOException: An unexpected network error occurred. : 'L:\logs20250828.txt'
at Microsoft.Win32.SafeHandles.SafeFileHandle.g__GetFileLengthCore|28_0()
at System.IO.Strategies.OSFileStreamStrategy.Seek(Int64 offset, SeekOrigin origin)
at System.IO.Strategies.BufferedFileStreamStrategy.Seek(Int64 offset, SeekOrigin origin)
at Serilog.Sinks.File.SharedFileSink.Serilog.Sinks.File.IFileSink.EmitOrOverflow(LogEvent logEvent)
at Serilog.Sinks.File.RollingFileSink.Emit(LogEvent logEvent)
at Serilog.Core.Sinks.SafeAggregateSink.Emit(LogEvent logEvent)

Appsettings Config:

"Serilog": {
"Using": [ "Serilog.Sinks.File" ],
"MinimumLevel": {
"Default": "Debug"
},
"WriteTo": [
{
"Name": "File",
"Args": {
"path": "L:\logs.txt",
"rollingInterval": "Day",
"outputTemplate": "{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {CorrelationId} {Level:u3} {SourceContext} {Message:lj}{Exception}{NewLine}",
"retainedFileCountLimit": 14,
"shared": "true"
}
}
]
}

[nblumhardt]

Hi Phil, thanks for the note. This is by design; the sink will pick back up at the next rolling checkpoint. Reducing the rolling interval will cause logging to resume sooner.

It'd be nice if the window were shortened, but care would be needed to avoid tanking application performance with reopen attempts (throwing exceptions is slow/inefficient, but trying to reopen the log file on each event is orders-of-magnitude slower again).

[grimchamp]

Hi, thanks for the quick response. So if I have daily rolling then I could have up to 24 hours of lost logging? This would be a big risk to our production environments. Would it not be better to check the location is accessible rather and gate reopen attempts behind that?