You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Guillermo Xavier Hurtado Garcia (Jira)" <ji...@apache.org> on 2019/08/22 19:20:00 UTC

[jira] [Resolved] (LOG4J2-2680) Not compressing after rolling a file using copy and truncation method

     [ https://issues.apache.org/jira/browse/LOG4J2-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guillermo Xavier Hurtado Garcia resolved LOG4J2-2680.
-----------------------------------------------------
    Resolution: Fixed

This issue has been resolved, changes has been submited and pull request is pending for approval at the following link:

[https://github.com/apache/logging-log4j2/pull/304]

> Not compressing after rolling a file using copy and truncation method
> ---------------------------------------------------------------------
>
>                 Key: LOG4J2-2680
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2680
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.6.2, 2.7, 2.8, 2.8.1, 2.8.2, 2.9.0, 2.9.1, 2.10.0, 2.11.0, 2.11.1, 2.11.2, 2.12.0, 2.12.1
>         Environment: Windows 2016 Server
>            Reporter: Guillermo Xavier Hurtado Garcia
>            Priority: Critical
>             Fix For: 2.12.1
>
>         Attachments: fix.png
>
>   Original Estimate: 1h
>          Time Spent: 10m
>  Remaining Estimate: 50m
>
> When log file has reached rolling size, method "execute" on "org.apache.logging.log4j.core.appender.rolling.action.FileRenameAction" class run as follows:
> 1. Move the log file to a new one using a new name;
>  2. If move fails, then it renames the log file;
>  3. If rename fails, then it copies the original file and then:
>      3.1 Deletes original file;
>      3.2 if delete fails, then it truncates the original file contents.
> Steps 2 and 3 are executed usually when original file is locked; after any successful step, the returning value should be "true", however after successfully executing step 3.2 it remains "false", avoiding the compression algorithm to be executed.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)