[
https://issues.apache.org/jira/browse/LOG4NET-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901150#comment-15901150
]
Stefan Bodewig commented on LOG4NET-556:
----------------------------------------
Many thanks, Steven
Oh my. {{RollingFileAppender}} really is broken in so many ways that small
patches threaten it to fall apart. I flinch every time I have to touch it.
LOG4NET-557
That being said, your patch deals one assumption (the pattern will always
contain yyyy-MM-DD) for another (if the parsed backup index is bigger than the
largest configured, it really must be a date). Your assumption is probably
closer to the truth than the current code, but there are edge cases like backup
files created with an older configuration that allowed for a bigger
{{maxSizeRollBackups}}.
There already is a comment in {{RollingFileAppender}}
{code}
// caution: we might get a false positive when certain
// date patterns such as yyyyMMdd are used...those are
// valid number but aren't the kind of back up index
// we're looking for
{code}
but I don't see anything that would handle this. I'd prefer code that dealt
with the potential "false positives" to go into {{InitializeFromOneFile}}
rather than having {{GetBackupIndex}} "lie".
> Rolling file appender only recognises dates in yyyy-MM-dd format.
> -----------------------------------------------------------------
>
> Key: LOG4NET-556
> URL: https://issues.apache.org/jira/browse/LOG4NET-556
> Project: Log4net
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.0.7
> Environment: Windows 7 and 10.
> Reporter: Steven Nicholas
> Priority: Minor
> Labels: fix
> Original Estimate: 10m
> Remaining Estimate: 10m
>
> Rolling file appender wouldn't recognise date format if it differed from
> yyy-MM-dd in the config file and would roll to the next file for every logged
> event, leading to thousands of files with the suffix yyyyMMdd-xxx.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
