Nlog: FileTarget.ArchiveAboveSize should roll to the next archive file if the previous archive file exceeds this limit

[jbe2277]

NLog version: 4.7.8

Platform: .NET Core 3.1 with WPF

Sample code: https://github.com/jbe2277/LoggingSample

Current NLog config

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" throwConfigExceptions="true">
  <targets>
    <target name="fileTarget" xsi:type="File" fileName="${specialfolder:folder=LocalApplicationData:cached=true}/NLogConfigSample/Log/App.log" 
            layout="${date:format=yyyy-MM-dd HH\:mm\:ss.ff} [${level:format=FirstCharacter}] ${processid} ${logger} ${message}  ${exception:format=tostring}"
            archiveAboveSize="10000" maxArchiveFiles="2" archiveNumbering="Sequence"/>
    <target name="traceTarget" xsi:type="Trace" rawWrite="true"
            layout="${date:format=yyyy-MM-dd HH\:mm\:ss.ff} [${level:format=FirstCharacter}] ${processid} ${logger} ${message}  ${exception:format=tostring}"/>
  </targets>

  <rules>
    <logger name="NLogConfigSample" minlevel="Trace" writeTo="fileTarget,traceTarget" />
    <logger name="SampleLibrary" minlevel="Trace" writeTo="fileTarget,traceTarget" />
  </rules>
</nlog>

https://github.com/jbe2277/LoggingSample/blob/master/LoggingSample/NLogConfigSample/NLog.config

• What is the current result?
  
  
  
  • App.log never exceeds the configured limit of 10kB (correct behavior)
  
  
  • App.0.log increases in size forever
  
  
• What is the expected result?
  
  
  
  • I need the size limit (e.g. ArchiveAboveSize) used also for archive files.
  
  
  • Example: App.0.log exceeds 10kB then it should write archive entries into App.1.log and so on.
  
  
  • Together with MaxArchiveFiles it would be possible to define the maximum disk space used by all log files together.
  
  
• Are there any workarounds? no
• Is there a version in which it did work? no

[welcome[bot]]

Hi! Thanks for opening your first issue here! Please make sure to follow the issue template - so we could help you better!

[snakefoot]

@jbe2277 Thank you for the bug-report. Can reproduce the issue. If you change the filename to this, then problem disappears:

fileName="${specialfolder:folder=LocalApplicationData:cached=true}/NLogConfigSample/Log/MyApp.log"

This is ofcourse a bug. I will create a pull-request for NLog 4.7.9

[snakefoot]

Created #4352 to resolve this issue.

[jbe2277]

Thanks for providing a workaround. It works now correct.

[jbe2277]

I have seen a strange behavior or maybe another bug.

As long the application is running the MaxArchiveFiles setting is enforced correctly. I have set it to 2. The log folder contains:

Application.log
Application.9.log
Application.10.log

But when I stop and start the application again it removes the oldest archive file right during start. The log folder contains then:

Application.log
Application.10.log

Sample to reproduce the behavior: https://github.com/jbe2277/LoggingSample

[snakefoot]

Yes it seems that NLog does a "application startup archive-cleanup" where it validates the current number of archive-files. When doing that check it sees 3 files:

Application.log
Application.9.log
Application.10.log

And removes the oldest file because MaxArchiveFiles=2. The "application startup archive-cleanup"-logic is different than "cleanup-before-new-archive-file"-logic.

Guess people using MaxArchiveFiles=30 does not notice that they become one file short, when doing application restarts.

NLog file-archive-logic started out with having archive-files in seperate folder. Think the "application startup archive-cleanup"-logic was never updated to corrrectly handle same-folder-archive.

But a fix should be made so "application startup archive-cleanup" and "cleanup-before-new-archive-file" is more similar.

[snakefoot]

Created extra pull-request #4353 to better handle same folder archive.

[304NotModified]

resolved by #4353

[snakefoot]

@jbe2277 NLog 4.7.9 has now been released: https://www.nuget.org/packages/NLog/4.7.9 (Fixes both issues reported)