Please correct me if I am wrong on this, but I believe the problem is due to the fact that the date/time format is customizable in the log file name. This makes it difficult to determine by name which log files to remove. Now, if one assumes that the date/time format used is sortable in a strictly-increasing manner (such as somelogfilenameYYYYMMDD.someextension) and no other variances exist in the filename format, then one can write a simple algorithm for the rolling file appender file cleanup part. But this imposes a hidden limitation based on an assumed naming convention.
Regards, Parx Shearer -----Original Message----- From: David Juffermans (JIRA) [mailto:[email protected]] Sent: Tuesday, August 25, 2009 2:44 AM To: [email protected] Subject: [jira] Commented: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files. [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747275#action_12747275 ] David Juffermans commented on LOG4NET-27: ----------------------------------------- So is this issue ever going to be fixed or what? > Rolling files on date/time boundaries doesn't support a maximum number of > backup files. > --------------------------------------------------------------------------------------- > > Key: LOG4NET-27 > URL: https://issues.apache.org/jira/browse/LOG4NET-27 > Project: Log4net > Issue Type: New Feature > Components: Appenders > Affects Versions: 1.2.11 > Reporter: Florian Ramillien > Priority: Minor > Fix For: 1.2.11 > > Attachments: RollingFileAppender.cs, RollingFileAppender.cs.patch, > RollingFileAppender.patch > > > A maximum of backup files exist when rolling files on file size, but not for > rolling on date/time. > This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
