[
https://issues.apache.org/jira/browse/LOG4J2-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342270#comment-17342270
]
jasonyu commented on LOG4J2-3090:
---------------------------------
Can we modify code like above ?
sync() will make sure the file was flushed successfully to the disk as
_java.io.FileDescriptor_ doc illustrated below:
/**
* Force all system buffers to synchronize with the underlying
* device. This method returns after all modified data and
* attributes of this FileDescriptor have been written to the
* relevant device(s). In particular, if this FileDescriptor
* refers to a physical storage medium, such as a file in a file
* system, {color:#FF0000}sync will not return until all in-memory modified
copies{color}
{color:#FF0000} * of buffers associated with this FileDesecriptor have
been{color}
{color:#FF0000} * written to the physical medium.{color}
{color:#FF0000}...{color}
*/
> Why the log file was deleted when the compressd file has not been flushed to
> the disk?
> --------------------------------------------------------------------------------------
>
> Key: LOG4J2-3090
> URL: https://issues.apache.org/jira/browse/LOG4J2-3090
> Project: Log4j 2
> Issue Type: Question
> Affects Versions: 2.13.3
> Reporter: jasonyu
> Priority: Minor
>
> Here is the situation :
> 1、The appender is RollingFileAppender with SizeBasedTriaggeringPolicy, the
> rolling file pattern is extended to ".gz".
> 2、While the log4j2 executing rolling(compress) event, the linux server is
> rebooted by coincidence.
> As a result, the log file before rolling was deleted and the size of the
> compressed file was zero, which means the log message was lost.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
