[ http://issues.apache.org/jira/browse/LOG4NET-86?page=comments#action_12424324 ] Nicko Cadell commented on LOG4NET-86: -------------------------------------
The only problem with rolling the counter back to 0 is if the appender is initialised with the existing files straddling the int max value: for example if the following files exist: Log.2147483645 Log.2147483646 Log.2147483647 Log.0 Log.1 Log.2 In this case the latest file is Log.2. Then when the RollingFileAppender is initialised it looks for the highest numbered file, i.e. 2147483647, it would then roll back to 0 and overwrite the files 0, 1, and 2. I'm assuming this would be a bad thing. Currently the m_curSizeRollBackups is stored and processed as an int, giving a max value of 2147483647. We could change this to a decimal giving a max value of 79228162514264337593543950335. This would postpone the problem rather than fix it, but it would postpone it for a rather long time. If we use decimals then you can roll a new file every millisecond for 2512308552583217199 years before the overflow condition is reached. > In RollingFileAppender when setting CountDirection=1 and the curr size reach > int.MaxValue > ----------------------------------------------------------------------------------------- > > Key: LOG4NET-86 > URL: http://issues.apache.org/jira/browse/LOG4NET-86 > Project: Log4net > Issue Type: Bug > Components: Appenders > Affects Versions: 1.2.10 > Environment: All > Reporter: Tal G > > In RollingFileAppender when setting CountDirection=1 and the curr size reach > int.MaxValue the log4net > 1. Open a new file with .-2147483648 extension. And stop deleting old files > for example file with extension .2147483638. > 2. When i restart my application, it start writing log on the file with > .-2147483648 although the newest file is with extension .-2147483643. > 3. etc.. many more bugs related to this issue > I suggest that when the file extension reach int.MaxValue move to 0 again and > continue properly deleting old files and opening new files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
