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. 

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 

There already is a comment in {{RollingFileAppender}} 

                // 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

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

Reply via email to