[
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.
