Snotface opened a new pull request, #334:
URL: https://github.com/apache/logging-log4net/pull/334
On start-up, `RollingFileAppender` counts the size backups already on disk
so the next roll continues from the highest one. It reads the number after the
last `.` of any matching file, which goes wrong in three ways:
1. **Dates read as backup numbers.** A date pattern without separators
(`.yyyyMMdd`) makes `log.txt.20261003` look like backup 20261003. Counting up,
the next backup is named `.20261004`. Counting down, every size roll walks the
names from 20 million down to 1: stock 2.0.5 made about 1.8 million rename
attempts on one roll before I stopped it.
2. **Backups lost on restart.** With `StaticLogFileName` false, a date
pattern that supplies the extension (`.yyyy-MM-dd'.log'`) and
`PreserveLogFileNameExtension`, the current date's backups
(`log.2026-10-04.1.log`) are skipped as "from a different date period". The
count restarts at 0 and the next size roll deletes the existing `.1`. In a
simulation of four app starts over two days, 114 of 160 lines survived, in both
2.0.5 and 3.5.1.
3. **Earlier dates counted as today's.** With a static file name, backups
already rolled to an earlier date (`log.txt.20261003.3`) raise the current
date's count, which leaves gaps in the numbering.
## Change
`GetBackupIndex` now builds the name the current date's backups must have,
the same way the appender names them (the base file, plus today's date when
`StaticLogFileName` is false, with the extension handled as
`PreserveLogFileNameExtension` does). It counts only files with that name plus
`.N`. With a static file name, a suffix that parses as a date in `DatePattern`
(`DateTime.TryParseExact`) is a dated file, not a backup.
### Short date patterns
With a static file name, a date pattern that formats as a short number
(`.dd`, `.MM`, `.HH`, `.yyyy`) names the dated file `log.txt.10` exactly like
backup 10, so one overwrites the other. No file name check can tell them apart.
Numbered backups are made by size rolls, and at start-up when `AppendToFile` is
false. So when the file name is static, the appender rolls by date,
`MaxSizeRollBackups` isn't 0, and the pattern can format as a dot plus at most
four digits, it makes no numbered backups:
- size rolling is switched off and `MaximumFileSize` is ignored
- when `AppendToFile` is false, the existing file is appended to at start-up
instead of being rolled out of the way
- the reason is written as a `FATAL` line at the top of each new file, past
the appender's filters and threshold, and as a log4net internal warning
Logging carries on and nothing throws. A configuration that never makes
numbered backups (`Date` style with `AppendToFile` true) is not affected.
The new `IgnoreDateWarnings` property (default `false`) keeps the configured
behaviour, exactly as before this change, for those who accept the risk.
The RollingFileAppender manual page has a new "Short date patterns" section,
and there's a changelog entry for 3.5.1.
## Testing
- `log4net.Tests`: net462 470 passed, 2 skipped; net10.0 454 passed, 1
skipped. `log4net.Ext.Mail.Tests`: 52 passed. The Release build of the solution
has 0 warnings.
- New tests cover:
- `.yyyyMMdd` with limited and unlimited backups, in both count directions
- counting up past the backup limit
- ignoring earlier dates
- a date pattern that supplies the extension
- a short pattern with a non-static name
- a short pattern switching size rolling off
- appending instead of rolling at start-up (Date and Composite)
- `IgnoreDateWarnings`
- Each scenario was also simulated through the built DLL, with app restarts
and date changes on a fake clock. Every configuration kept every line, and
`IgnoreDateWarnings` produced the same files as stock 2.0.5.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
