corretto/corretto-8

java.nio.Files.readAttributes() truncates file timestamps

Opened this issue · 4 comments

timothyg-stripe commented

This bug is specific to Corretto 8. It cannot be reproduced under

  • Azul Zulu 8.78.0.19 (JDK 8.0.412+8)
  • Eclipse Temurin 8.0.412+8
  • Amazon Corretto 11.0.23.9.1

Describe the bug

On Linux x86-64, file ctime, mtime, and atime returned from Corretto 8 java.nio.Files.readAttributes() only have second precision. This seems to be caused by a lack of these lines from OpenJDK in Corretto 8. It causes Corretto to act in a different way compared to other OpenJDK vendors.

Confusingly, java.io.File.lastModified() does return timestamps with millisecond precision, making Corretto internally inconsistent.

To Reproduce

TestFileTime.java:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributes;

public class TestFileTime {
  public static void main(String[] args) throws IOException {
    Path newFile = Files.createTempFile("", "");
    newFile.toFile().deleteOnExit();

    System.out.println("mtime");
    System.out.println(newFile.toFile().lastModified());
    System.out.println(Files.readAttributes(newFile, BasicFileAttributes.class).lastModifiedTime().toMillis());

    System.out.println("ctime");
    System.out.println(Files.readAttributes(newFile, BasicFileAttributes.class).creationTime().toMillis());

    System.out.println("atime");
    System.out.println(Files.readAttributes(newFile, BasicFileAttributes.class).lastAccessTime().toMillis());
  }
}
$ /tmp/amazon-corretto-8.412.08.1-linux-x64/bin/javac TestFileTime.java
$ /tmp/amazon-corretto-8.412.08.1-linux-x64/bin/java TestFileTime
mtime
1718127878359
1718127878000
ctime
1718127878000
atime
1718127878000

Expected behavior

I expect the two ways to get file mtime (via java.io and java.nio) to return the same value (one with millisecond precision). I also expect ctime and atime to return timestamps with millisecond precision. This is the behavior on Azul Zulu and Eclipse Temurin.

$ /tmp/zulu8.78.0.19-ca-jdk8.0.412-linux_x64/bin/java TestFileTime
mtime
1718128167921
1718128167921
ctime
1718128167921
atime
1718128167921
$ /tmp/temurin/jdk8u412-b08/bin/java TestFileTime
mtime
1718128176913
1718128176913
ctime
1718128176913
atime
1718128176913

Platform information

OS:

$ uname -srvo
Linux 5.15.0-1062-aws #68~20.04.1-Ubuntu SMP Wed May 1 15:24:09 UTC 2024 GNU/Linux

Version:

openjdk version "1.8.0_412"
OpenJDK Runtime Environment Corretto-8.412.08.1 (build 1.8.0_412-b08)
OpenJDK 64-Bit Server VM Corretto-8.412.08.1 (build 25.412-b08, mixed mode)
timothyg-stripe commented

Looks like the operative code was (accidentally?) removed in 7b6d16b#diff-8e35b358b547148e08382745171514dd7efb6958f14e6ac55bf98c5a970639d9

mrserb commented

Hello @timothyg-stripe thank you for your report.

Some time ago that code path was intentionally deleted to not change "old behavior" of that method for compatibility.

We are investigating whether we can enable this code path now or not.

timothyg-stripe commented

@mrserb Note though: I would expect java.io.File.lastModified() to have more compatibility impact than NIO, but the behavior of that was changed in 4b000c7

mrserb commented

correct, we found the issues only with other method. Still looking into this.