On Tue, 18 Nov 2025 10:03:43 GMT, Jaikiran Pai <[email protected]> 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
