search

dfacto-lab / serilog-sinks-file

Serilog file sinks duplicated for file rolling
Apache License 2.0
14 stars 10 forks source link

A LogEvent with length > 4096 (DefaultFileStreamBufferLength) will not be persisted to file #24

Closed MelvLee closed 3 months ago

MelvLee commented 7 months ago

A LogEvent that leads to a writeBuffer with length > 4096 (DefaultFileStreamBufferLength) will not be persisted to file. This is caused by the following exception thrown in the IFileSink.EmitOrOverflow method of the SharedFileSink class in SharedFileSink.AtomicAppend.cs file

System.ArgumentException
  HResult=0x80070057
  Message=Append access can be requested only in write-only mode. (Parameter 'options')
  Source=System.Private.CoreLib
  StackTrace:
   at System.IO.FileStream..ctor(String path, FileStreamOptions options)
   at Serilog.Sinks.PersistentFile.SharedFileSink.Serilog.Sinks.PersistentFile.IFileSink.EmitOrOverflow(LogEvent logEvent) in C:\Projects\brp-api\brp-shared-dotnet\src\Serilog.Sinks.PersistentFile\Sinks\PersistentFile\SharedFileSink.AtomicAppend.cs:line 102
   at Serilog.Sinks.PersistentFile.RollingFileSink.Emit(LogEvent logEvent) in C:\Projects\brp-api\brp-shared-dotnet\src\Serilog.Sinks.PersistentFile\Sinks\PersistentFile\RollingFileSink.cs:line 96
   at Serilog.Core.Sinks.SafeAggregateSink.Emit(LogEvent logEvent)

The exception is not thrown anymore when the Access property value is changed from FileAccess.ReadWrite to FileAccess.Write (line 105)

All unit tests are passing with this modification, but since I noticed the SharedFileSink class is marked as obsolete, I want to check if I should make a pull request for this modification. I see that the SharedFileSink is used when the shared parameter is set to true, which is how I have configured the file sink in my containerized application.

numito commented 3 months ago

Thank you for spotting that. Those the content gets persistent correctly with FileAccess.Write ?

MelvLee commented 3 months ago

Thank you for spotting that. Those the content gets persistent correctly with FileAccess.Write ?

I have used the fix since April and the logevents are still logged correctly