[
https://issues.apache.org/jira/browse/LOGCXX-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Buijs updated LOGCXX-464:
---------------------------------
Description:
I'm using log4cxx 0.10.0 configured through xml to use a RollingFileAppender
that rolls/triggers using a TimeBasedRollingPolicy.
* The append property on the RollingFileAppender is true.
* The FileNamePattern of the TimeBasedRollingPolicy is set to use the following
pattern: {code}%d{yyyyMMdd.HH}.log{code}
This setup I use in an embedded system that is not directly connected to the
internet and has no battery powered rtc. This means that the system time is
always 1970-01-01 01:00:00 at boot, normally time is synchronized by the user
after boot.
In this case the following situation can occur:
# Current time is 2016-04-05 15:20:00, my application is logging to
{code}20160405.15.log{code}
# User restarts the system, time is now 1970-01-01 01:00, my application starts
at boot and starts logging to {code}19700101.01.log{code}
# User synchronizes time to 2016-04-05 15:25:00. Now the application truncates
{code}20160405.15.log{code} and start writing logs to it.
I've traced the cause of this down to 1 line in timebasedrollingpolicy.cpp, in
the end of ::rolover:
{code}
return new RolloverDescription(
nextActiveFile, false, renameAction, compressAction);
{code}
In this line append is hardcoded to false, instead of using the append property.
was:
I'm using log4cxx 0.10.0 configured through xml to use a RollingFileAppender
that rolls/triggers using a TimeBasedRollingPolicy.
* The append property on the RollingFileAppender is true.
* The FileNamePattern of the TimeBasedRollingPolicy is set to use the following
pattern: {code}%d{yyyyMMdd.HH}.log{code}
This setup I use in an embedded system that is not directly connected to the
internet and has no battery powered rtc. This means that the system time is
always 1970-01-01 01:00:00 at boot, normally time is synchronized by the user
after boot.
In this case the following situation can occur:
# Current time is 2016-04-05 15:20:00, my application is logging to
{code}20160405.15.log{code}
# User restarts the system, time is now 1970-01-01 01:00, my application starts
at boot and starts logging to {code}19700101.01.log{code}
# User synchronizes time to 2016-04-05 15:25:00. Now the application truncates
{code}20160405.15.log{code} and start writing logs to it.
> TimeBasedRollingPolicy should append as configured on rollover
> --------------------------------------------------------------
>
> Key: LOGCXX-464
> URL: https://issues.apache.org/jira/browse/LOGCXX-464
> Project: Log4cxx
> Issue Type: Bug
> Components: Appender
> Affects Versions: 0.10.0
> Environment: Win32, Linux
> Reporter: Martijn Buijs
>
> I'm using log4cxx 0.10.0 configured through xml to use a RollingFileAppender
> that rolls/triggers using a TimeBasedRollingPolicy.
> * The append property on the RollingFileAppender is true.
> * The FileNamePattern of the TimeBasedRollingPolicy is set to use the
> following pattern: {code}%d{yyyyMMdd.HH}.log{code}
> This setup I use in an embedded system that is not directly connected to the
> internet and has no battery powered rtc. This means that the system time is
> always 1970-01-01 01:00:00 at boot, normally time is synchronized by the user
> after boot.
> In this case the following situation can occur:
> # Current time is 2016-04-05 15:20:00, my application is logging to
> {code}20160405.15.log{code}
> # User restarts the system, time is now 1970-01-01 01:00, my application
> starts at boot and starts logging to {code}19700101.01.log{code}
> # User synchronizes time to 2016-04-05 15:25:00. Now the application
> truncates {code}20160405.15.log{code} and start writing logs to it.
> I've traced the cause of this down to 1 line in timebasedrollingpolicy.cpp,
> in the end of ::rolover:
> {code}
> return new RolloverDescription(
> nextActiveFile, false, renameAction, compressAction);
> {code}
> In this line append is hardcoded to false, instead of using the append
> property.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
