[
https://issues.apache.org/jira/browse/LOG4J2-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506867#comment-17506867
]
Gary D. Gregory edited comment on LOG4J2-3432 at 3/15/22, 11:48 AM:
--------------------------------------------------------------------
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.1.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a bug or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
was (Author: garydgregory):
My POV is different obviously: if there is anything for us to fix, it would be
for the next release, so we would debug the current code or at worse the
current released code tag. This due to the fact that we would not release a
maintenance version "in between" older versions (Log4Shell was a kind of an
exception), IOW we would not release a 2.17.0.1, instead we would put a fix in
the next release, currently labeled 2.17.3. So to me it makes the most sense to
have a big or behavior confirmed on the most recent release because it has the
least amount of cumulative difference with the current git code and the least
chance for possible side effects. This goes along with my time management as a
volunteer here, waste little of my time, ask users to share in the word, we all
benefit.
> RollingFileAppender fails after 100 backup cycles if filePattern contains
> "%04i" .
> ----------------------------------------------------------------------------------
>
> Key: LOG4J2-3432
> URL: https://issues.apache.org/jira/browse/LOG4J2-3432
> Project: Log4j 2
> Issue Type: Bug
> Components: Appenders
> Affects Versions: 2.17.1, 2.17.2
> Environment: * Red Hat Enterprise Linux Server release 6.10 (Santiago)
> * java version "1.8.0_181"
> Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)
> * 301873 Mar 9 07:53 log4j-api-2.17.1.jar
> 1790452 Mar 9 07:53 log4j-core-2.17.1.jar
>
> Reporter: Carl Smotricz
> Assignee: Ralph Goers
> Priority: Major
> Attachments: Main.java, log4j2.xml, runit.sh
>
>
> 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:
> {quote}... 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.
> {quote}
> ...but I haven't verified that the problem occurs with that appender as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
