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:
jira@...]
Sent: Tuesday, August 25, 2009 2:44 AM
To:
log4net-dev@...
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.
