Thank you for your feedback. From your previous reply I now understand that the default value of maxSizeRollBackups is 0.
Documentation mentions that to keep all backups the value of the property should be negative number. This worked as expected. I would be happy to open a new JIRA. However I am not clear about the actual issue to be mentioned. My initially confusion was related to the behaviour of RollingFileAppender with default value of maxSizeRollBackups.(also with value 0) For value = 0 the API documentation states "If set to zero, then there will be no backup files and the log file will be truncated when it reaches MaxFileSize Property". Does this mean that it should not generate new log file on reaching max file size. Should it start overwriting the original file? The observations that I mentioned were based on default value of maxSizeRollBackups. RollingFileAppender rolled on size and kept generating new log files while the application was running. On application restart it started by overwriting the 2nd log file (from previous run). I got the same results by setting the value to 0. Thanks and Regards Mohkam Singh >________________________________ > From: Stefan Bodewig <bode...@apache.org> >To: Log4NET User <log4net-user@logging.apache.org> >Cc: Mohkam Singh Sawhney <singh...@yahoo.com> >Sent: Friday, August 15, 2014 4:21 PM >Subject: Re: RollingFileAppender overwriting previous log files on application >restart > > >On 2014-08-14, Mohkam Singh Sawhney wrote: > >> I am using log4Net v1.2.13 in a .NET 4 C# project. I have setup a >> RollingFileAppender to roll on size. My aim is to keep appending to a >> log file and roll on size. I need to maintain all the previous log >> files. But I found that every time my application restarts all the log >> files after the 2nd log file that was generated in the previous run >> get overwritten. > >To be honest, RollingFileAppender is the source of most of our bug >reports and I don't think anybody of the current team feels comfortable >touching it. It's more than about time to rewrite it. > >You are providing excellent information that will help us reproducing >the issue, it would be a shame to lose that, so please open a new JIRA >issue with it. > >> A similar scenario described in this issue tracker - LOG4NET-378. The >> bug has been closed with resolution fixed in v1.2.12. > >Looking at the patch that resolved it[1] the patch only applies to the >case where you are rolling on date boundaries (and maybe on size as >well), a sibbling of the issue may be lurking in the branch that apploes >to "pure" rolling on size. > >> I would appreciate it if somebody could confirm the following points > >> 1. What is the default value of maxSizeRollBackups if it is not >> mentioned in the config file. I could not find this in documentation >> for this property. > >The default value is 0, I'll look into updating the docs. > > >> 2. For the scenario that I described is expected to include >> maxSizeRollBackups=-1 in the config file? > >At least to a value != 0. 0 means not to keep any backups and I think >what you expierence is an off by one error and the code was supposed to >overwrite the first log file first rather than the second. > >Stefan > > > >
