RollingFileAppender fails after 100 backup cycles if filePattern contains "%04i" .

If a %i formatter in a filePattern includes a width specifier, e.g. "%4i" or "%04i", file renaming fails after a certain fixed number of cycles. After that, successive backups are renamed to the maximum cycle number and overwrite previous files of that same cycle number, regardless of min and max settings on the appender. Here are some failure modes I've found by testing:

• if filePattern contains %06i, cycling breaks after 100.
• if filePattern contains %006i, it breaks after 100 also.
• if filePattern contains %6i, it breaks after 10.
• if filePattern contains %06i and DefaultRolloverStrategy.min=10000, max=99999, it breaks after just 1.

Now, the doc doesn't mention the %i spec supporting width and leading zero modifiers in the manner of printf() or String.format() . Yet, those variations (which I think other users will also be tempted to try) work - until they don't. So apparently width and padding on that spec are implemented but buggy.

The doc for RollingRandomAccessFileAppender explicitly recommends these format modifiers:

... and/or a %i which represents an integer counter. The integer counter allows specifying a padding, like %3i for space-padding the counter to 3 digits or (usually more useful) %03i for zero-padding the counter to 3 digits.

...but I haven't verified that the problem occurs with that appender as well.