You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by "Nicko Cadell (JIRA)" <ji...@apache.org> on 2005/07/22 22:26:47 UTC

[jira] Commented: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

    [ http://issues.apache.org/jira/browse/LOG4NET-27?page=comments#action_12316506 ] 

Nicko Cadell commented on LOG4NET-27:
-------------------------------------

I think that this date period cleanup logic should go in the RollOverTime method rather than OpenFile.

Rather than reusing MaxSizeRollBackups I think that we need another property, MaxDatePeriods, to control the number of date periods archived. This is because when RollingStyle=Composite the output is split into date periods, but within each period the files are size rolled and the MaxSizeRollBackups property is used to control how many size rolled files should be kept per date period. As we would want to be able to combine the number of date periods with the number of size rolled files we would need another property to do this.

Because of the composite mode it is also necessary to delete any size rolled files within the date period. These would be called logfile.txt2005-07-22.txt.1, logfile.txt2005-07-22.txt.2 etc... i.e. they have a numbered postfix on the file name.

> Rolling files on date/time boundaries doesn't support a maximum number of backup files.
> ---------------------------------------------------------------------------------------
>
>          Key: LOG4NET-27
>          URL: http://issues.apache.org/jira/browse/LOG4NET-27
>      Project: Log4net
>         Type: New Feature
>   Components: Appenders
>     Reporter: Florian Ramillien
>     Priority: Minor
>  Attachments: 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.
-
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