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

[sendaoYan]

Hi all,

Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS).

Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check.

But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time.

Change has been verified locally on XFS file system and ext4 file system.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8371978: tools/jar/ReproducibleJar.java fails on XFS (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/28367/head:pull/28367
$ git checkout pull/28367

Update a local copy of the PR:
$ git checkout pull/28367
$ git pull https://git.openjdk.org/jdk.git pull/28367/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28367

View PR using the GUI difftool:
$ git pr show -t 28367

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/28367.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back syan! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[sendaoYan]

/issue JDK-8371978

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@sendaoYan This issue is referenced in the PR title - it will now be updated.

[openjdk]

@sendaoYan The following label will be automatically applied to this pull request:

• core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (f9ee5521)

[jaikiran]

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.

[sendaoYan]

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.