RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS

[SendaoYan]

On Tue, 18 Nov 2025 10:03:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @sendaoYan, the failure here is because the extracted date/time on the directory does not match the one in the JAR file's entry for that directory (due to the underlying filesystem). Would it be possible to see which part of the JDK code is setting this date on that directory to the Unix epoch time? I haven't had a chance to go over the JAR tool's code in detail.

The JAR file's entry save the correct date/time. 'jar --extract' create the directory through method `void extract(String fname, String[] files)` in jdk.jartool/sun/tools/jar/Main.java:1434, then `ZipEntry extractFile(InputStream is, ZipEntry e)` will call `File.setLastModified(long time)` to change the modify time.  The call shows below.


void extract(String fname, String[] files)
->
ZipEntry extractFile(InputStream is, ZipEntry e)
->
File.setLastModified(long time)
->
java.io.UnixFileSystem.setLastModifiedTime(File f, long time)
->
private native boolean setLastModifiedTime0(File f, long time)
->
Java_java_io_UnixFileSystem_setLastModifiedTime0(JNIEnv *env, jobject this,jobject file, jlong time)
->
linux system call utimes


The linux system call utimes get the correct 64bit modified date/time, but the file system only support 32bit data/time. So the system call utimes set the directory to the Unix epoch time.

The jdk.jartool/sun/tools/jar/Main.java:1524 call File.setLastModified(long time), but do not check the return value. Do this should be improved.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3565508983