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 "Florian Ramillien (JIRA)" <ji...@apache.org> on 2005/04/25 00:03:23 UTC
[jira] Created: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
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
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
RE: [jira] Commented: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Posted by Parx Shearer <Pa...@medhost.com>.
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@apache.org]
Sent: Tuesday, August 25, 2009 2:44 AM
To: log4net-dev@logging.apache.org
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.
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "Lieven Cardoen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924569#action_12924569 ]
Lieven Cardoen commented on LOG4NET-27:
---------------------------------------
Does this work now in the source control current revision version?
> 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: LOG4NET-27.patch, 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.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries
doesn't support a maximum number of backup files.
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ron Grabowski updated LOG4NET-27:
---------------------------------
Affects Version/s: 1.2.11
Fix Version/s: (was: v.Next)
1.2.11
> 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.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.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Posted by "Florian Ramillien (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/LOG4NET-27?page=all ]
Florian Ramillien updated LOG4NET-27:
-------------------------------------
Attachment: RollingFileAppender.cs.patch
More appropriate patch
- Now work with rolling other than by Day
- based on CVS, not last beta
But : Logic to delete file in 'OpenFile' method, is it the good place ?
> 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
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "David Juffermans (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "Ron Grabowski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716776#action_12716776 ]
Ron Grabowski commented on LOG4NET-27:
--------------------------------------
Thanks for the patch! Is there anyway you can write the patch against the current revision in source control? There's been a number of largish pages since the 1.2.10 release. I haven't diff'ed the two files yet...maybe its just a simple copy paste of one or two methods and fixing wrapping the file IO calls to be called within the correct context like the calls to File.Move and File.Delete.
I'm not sure I follow this code:
else if (!byte.TryParse(current.Substring(charLoop, 1), out dummyByte))
Will that work if the numbers are not single digits: 10, .11, .12 ?
I don't understand the need for PreviousCheckDate. Can't you determine the previous and current files by capturing the parameters to RollFile?
None of the other file rolling code looks at the file system's date modified time...its all based on the filename. I wonder if this inconsistency will cause unexpected behavior.
My idea was to change the signature of RollFile to return the name of the rolled file, create a list of rolled files, then iterate through that list and determine which of the new files are over the MaxDateRollBackups threshold and delete those files. I don't think it should take a lot of code to implement this functionality.
> 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.
[jira] Issue Comment Edited: (LOG4NET-27) Rolling files on
date/time boundaries doesn't support a maximum number of backup files.
Posted by "Petr Felzmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212 ]
Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:43 PM:
----------------------------------------------------------------
I created patch from Joshua Masek changes against the current revision in source control. Hope it moves this issue little bit forward.
Personally I'm still on the way to understand the code to be able implement ideas from Ron's comment (05/Jun/09 10:28).
Also I'm very surprised how the unit tests are complicated. I'd like to write unit tests for this change... but there are missing completely unit tests for anything concerning date/time :-(
was (Author: felzmann):
I created patch from Joshua Masek changes against the current revision in source control. Hope it moves this issue little bit forward.
Personally I'm still on the way to understand the code to be able implement ideas from Ron's comment (05/Jun/09 10:28).
Also I'm very surprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
> 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: LOG4NET-27.patch, 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.
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "Joshua Masek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716890#action_12716890 ]
Joshua Masek commented on LOG4NET-27:
-------------------------------------
Yeah, I'm not sure I implemented it the best way. It was more of a workaround against the current release until similar functionality makes it into the official build, and I posted it at least to make it available to others that could use the functionality now.
When I get more time (might have to be weeks or months), I might have a chance to make a better patch and base it on the newest revision.
As for the digits like .10, .11., etc. Its looping thru the characters from the end of the string looking for either digits or a period. At the time, that was the way it occurred to check if the char was a digit. (Now, I realize I could simply do something like >= "0" and <= "9" or something. But, I didn't test with more than 4... so, I should test that.
When rolling sizes, then the files extensions (.1, .2, .3, etc) are getting renamed. When rolling dates, they aren't, so there isn't any previous file identified.
Actually, there was some code that looked at the system's date modified time, although in a different function in that class.
Your last comment about your idea:
The problem I had was this:
(well, first, files are rolled/renamed in the size functionality, not the date functionality, except for the initial rename from the basefilename to the filename with the date format embedded)
there could be files sitting there that need deleted from a lot longer ago than the MaxDateRollBackups value allows, and these files need deleted (they still exist because, say, the program hasn't been in awhile). So, somehow those files have to be identified. They have the formatted date inside of it. How to find all file with the base filename and a date formatted with that format (and also potentially any size extensions on them)? Some date formats can be difficult to parse from the string back into the date. Especially the ones that spit out long names and such. They can throw all kind of crazy formats into those files. Using a basic * wildcard works easily, but could cause files to be deleted that aren't desired to be deleted. LIke if someone renamed it manually with a descriptive extention to save the file. I'm not sure if it is wise, but to be safe and not delete files that shouldn't be deleted, I figured looping thru the files based on the simple * wildcard, skipping the ones we know are still good within the MaxDateRollBackups and MaxSizeRollBackups limits, we can take the rest, get each ones' modified timestamp, format that timestamp, compare against the formatted timestamp in the filename, if it matches exactly, then it hasn't been renamed, and can be deleted. Also, check the previous check timestamp prior to the modified timestamp, because the file could have been modified as it was crossing the boundary.
I'm just not sure if there are any reasons not to trust the modified timestamp. But I didn't know how else to successfully remove those files, and not files that I renamed.
As a note, my method using modified timestamps may not work well if the date format has seconds or milliseconds in it.
I'm not suggesting log4net do it that way, its just the only way I could do it and correctly have it decide to delete or not delete each file.
> 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.
[jira] Issue Comment Edited: (LOG4NET-27) Rolling files on
date/time boundaries doesn't support a maximum number of backup files.
Posted by "Petr Felzmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212 ]
Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:42 PM:
----------------------------------------------------------------
I created patch from Joshua Masek changes against the current revision in source control. Hope it moves this issue little bit forward.
Personally I'm still on the way to understand the code to be able implement ideas from Ron's comment (05/Jun/09 10:28).
Also I'm very surprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
was (Author: felzmann):
I created patch from Joshua Masek changes against the current revision in source control. Hope it moves this issue little bit forward.
Personaly I'm still on the way to understand the code to be able implement ideas from Ron's comment (05/Jun/09 10:28).
Also I'm very supprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
> 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: LOG4NET-27.patch, 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.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries
doesn't support a maximum number of backup files.
Posted by "Joshua Masek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua Masek updated LOG4NET-27:
--------------------------------
Attachment: RollingFileAppender.cs
> 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.
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "David Juffermans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669895#action_12669895 ]
David Juffermans commented on LOG4NET-27:
-----------------------------------------
Unbelievable this isn't in there yet. So for almost 4 years already people using a (daily) rolling file appender have to clean up log files manually?
> 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
> Reporter: Florian Ramillien
> Priority: Minor
> Fix For: v.Next
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Posted by "Nicko Cadell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/LOG4NET-27?page=all ]
Nicko Cadell updated LOG4NET-27:
--------------------------------
Fix Version: v.Next
Description:
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
was:
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
Environment:
> 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
> Fix For: v.Next
> 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
[jira] Issue Comment Edited: (LOG4NET-27) Rolling files on
date/time boundaries doesn't support a maximum number of backup files.
Posted by "Petr Felzmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212 ]
Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:41 PM:
----------------------------------------------------------------
I created patch from Joshua Masek changes against the current revision in source control. Hope it moves this issue little bit forward.
Personaly I'm still on the way to understand the code to be able implement ideas from Ron's comment (05/Jun/09 10:28).
Also I'm very supprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
was (Author: felzmann):
This is patch created from last attachment posted by Joshua Masek.
> 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: LOG4NET-27.patch, 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.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Posted by "Florian Ramillien (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/LOG4NET-27?page=all ]
Florian Ramillien updated LOG4NET-27:
-------------------------------------
Attachment: RollingFileAppender.patch
On 'OpenFile', build all valid backup file names and delete all backup files that don't match this list.
> 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.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
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "David Imboden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856365#action_12856365 ]
David Imboden commented on LOG4NET-27:
--------------------------------------
Will be very important for CompactFramework, mobile computers do not have much capacity.
> 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: LOG4NET-27.patch, 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.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "Joshua Masek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716324#action_12716324 ]
Joshua Masek commented on LOG4NET-27:
-------------------------------------
I'm surprised this feature is still missing. Automatically rolling and deleting old logs by date is often the preferred method asked of me.
> 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
> Reporter: Florian Ramillien
> Priority: Minor
> Fix For: v.Next
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-27) Rolling files on date/time
boundaries doesn't support a maximum number of backup files.
Posted by "Joshua Masek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12716685#action_12716685 ]
Joshua Masek commented on LOG4NET-27:
-------------------------------------
I made the change for myself so that I could have the functionality now. I tried to keep the change compatible with the other options:
- I started with the RollingFileAppender.cs.patch
- I moved the logic into RollOverTime
- I created a new property: MaxDateRollBackups
- I made sure it deleted log files with combination of date and rolled by size
- I don't delete files where the filename doesn't match the last modified timestamp or the previous check timestamp prior to the last modified timestamp. This was so that it would not delete files like logfile.txt2005-07-22.txt.1.keepThisForFutureReference
- I made sure it works for when staticLogFileName is true or false
- I'm attaching my version of the RollingFileAppender.cs file. It was based of the v1.2.10.0 build.
> 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.
[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries
doesn't support a maximum number of backup files.
Posted by "Petr Felzmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Petr Felzmann updated LOG4NET-27:
---------------------------------
Attachment: LOG4NET-27.patch
This is patch created from last attachment posted by Joshua Masek.
> 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: LOG4NET-27.patch, 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.
[jira] Commented: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
Posted by "Nicko Cadell (JIRA)" <ji...@apache.org>.
[ 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