LastModifiedTime of compressed file is not preserved

[mourya-satyam-888]

Description

I am using the RollingFileAppender with GZ compression, I have observed that renaming of the file is done correctly but after the compression the modified time is not preserved for the compressed file.
unlike in gzip or logrotate it preserve the Modified time from source.

is there any way to configure this, as per code POSIX action only have file permission, owner and group settings.

There is no explicit way of having same timestamp as source.

Configuration

Version: [Log4j version]
2.17.1

[vy]

@mourya-satyam-888, AFAIK, Log4j indeed does not strive to preserve the source timestamp. This need is new to us – would you mind providing a little bit more context, please? What is the technical obstacle you're trying to overcome by preserving the timestamp?

Alternatively, you can programmatically implement this yourself by implementing your custom RolloverListener – see RollingDirectSize3490Test.java for inspiration:

logging-log4j2/log4j-core-test/src/test/java/org/apache/logging/log4j/core/appender/rolling/RollingDirectSize3490Test.java

Lines 79 to 80 in 9643c22

	final RollingFileAppender app = context.getConfiguration().getAppender("RollingFile");
	app.getManager().addRolloverListener(this);

[mourya-satyam-888]

Hi @vy

Thanks for the response.

We are streaming our application logs to some data store using our own agent.

Where we have logic around the sorting files based on modified time and inode to find the next file to stream. It is working as expected using logrotate or gzip utility as it preserve the modified time of renamed file, but the log4j2 its not working as expected.

As sometime the order becomes(sorted based on mtime):
{ public.log, public-2025-10-28.log.1.gz }

We are not sure if that is the expected behaviour from log4j2, as gzip and other utility works as expected.

Appreciate your feedback on the same

[vy]

@mourya-satyam-888, thanks for providing more context, much appreciated.

I can observe the logrotate behavior you shared:

$ cd /tmp/logrotate-workbench
$ ls -la --time-style=long-iso
total 64
drwxrwxr-x 2 root root 4096 2025-10-28 09:23 .
drwxrwxrwt 107 root root 49152 2025-10-28 09:20 ..
-rw-rw-r-- 1 vy vy 1025 2015-10-28 09:16 foo.log
-rw------- 1 root root 104 2025-10-28 09:06 logrotate.conf

$ sudo cat logrotate.conf
/tmp/logrotate-workbench/foo.log {
size 1k
rotate 4
compress
missingok
notifempty
}

$ sudo logrotate --state ./logrotate.state --force ./logrotate.conf
$ ls -la --time-style=long-iso foo*
-rw-rw-r-- 1 vy vy 1048 2015-10-28 09:16 foo.log.1.gz

Note that foo.log of 2015 is rotated to foo.log.1.gz of, again, 2015. I guess we can implement a similar behavior in Log4j by adapting PosixViewAttributeAction.

@mourya-satyam-888, would you be interested in contributing this feature? You can either do this in isolation, or we can assist you. Either case, I strongly advise you to outline your plan before writing any lines of code.