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

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 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
• Fix Version/s: 2.12.1
• Component/s: Core

Environment

Windows 2016 Server

• Flags: Patch, Important
• Assignee: Unassigned
• Reporter: Guillermo Xavier Hurtado Garcia
• Created: 22/Aug/19 16:33
• Updated: 22/Feb/20 23:33
• Resolved: 22/Aug/19 19:19

Description

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.

Issue Links

• is duplicated by: LOG4J2-1726 RollingFile appender doesn't gzip and rolling log archives
• links to: GitHub Pull Request #304