There is a fix in Java 10 that increases the precision for File.lastModified
(https://bugs.openjdk.java.net/browse/JDK-8177809 ). My issue is that the two
methods (File.lastModified and BasicFileAttributes.lastModifiedTime) behave
differently depending on the gcc version. And this is not addressed by the JDK
10 patch either.
Find my original patch below. It addresses the Java 8 issue but would work if
JDK-8177809 is back-ported.
Cheers,
Martin
diff --new-file --unified --recursive --exclude='*.autotools'
--exclude='*.cproject' --exclude='*.project'
./jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
/home/schaef/jgitevidence/8src/src/OpenJDK8Src/edit-src/jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
--- ./jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c 2017-10-20
20:28:26.000000000 +0000
+++
/home/schaef/jgitevidence/8src/src/OpenJDK8Src/edit-src/jdk/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c
2017-11-15 22:04:25.103588607 +0000
@@ -453,11 +453,11 @@
(*env)->SetLongField(env, attrs, attrs_st_birthtime_sec,
(jlong)buf->st_birthtime);
#endif
-#if (_POSIX_C_SOURCE >= 200809L) || defined(__solaris__)
- (*env)->SetLongField(env, attrs, attrs_st_atime_nsec,
(jlong)buf->st_atim.tv_nsec);
- (*env)->SetLongField(env, attrs, attrs_st_mtime_nsec,
(jlong)buf->st_mtim.tv_nsec);
- (*env)->SetLongField(env, attrs, attrs_st_ctime_nsec,
(jlong)buf->st_ctim.tv_nsec);
-#endif
+//if (_POSIX_C_SOURCE >= 200809L) || defined(__solaris__)
+ // (*env)->SetLongField(env, attrs, attrs_st_atime_nsec,
(jlong)buf->st_atim.tv_nsec);
+ // (*env)->SetLongField(env, attrs, attrs_st_mtime_nsec,
(jlong)buf->st_mtim.tv_nsec);
+ // (*env)->SetLongField(env, attrs, attrs_st_ctime_nsec,
(jlong)buf->st_ctim.tv_nsec);
+//endif
}
JNIEXPORT void JNICALL
On 11/24/17, 10:54 AM, "Alan Bateman" <[email protected]> wrote:
On 24/11/2017 14:53, Schaef, Martin wrote:
> We are experiencing a problem with the following test case:
>
https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L364
>
> Depending on which gcc version we use to compile OpenJDK, the assertion
in
https://github.com/eclipse/jgit/blob/master/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CheckoutCommandTest.java#L397
fails.
> That is, the methods
java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()
> and java.io.File.lastModified() return results with a different precision.
>
> We root-caused it to the following code block in UnixNativeDispatcher.c:
>
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/07011844584f/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c#l456
>
> The test case at the bottom of this email can be used to reproduce the
behavior. When using a JDK compiled with gcc 4.1.2, the test prints:
> nio 1511387180000
> io 1511387180000
> But when using a JDK compiled with gcc 4.4.6, the code returns:
> nio 1511387187817
> io 1511387187000
> Exception in thread "main" java.lang.RuntimeException: 1511387187817 !=
1511387187000
> at Issue225.testLastModified(Issue225.java:33)
> at Issue225.main(Issue225.java:11)
>
> In comparison, the OracleJDK binaries as downloaded from the website
behave like the gcc 4.1.2 compiled binaries. To avoid confusion, and to ensure
that both methods behave the same, we propose to remove the block in
UnixNativeDispatcher.c (see attached patch).
>
We should the higher precision time stamps when available, it's just
awkward that it gets compiled or not depending on the header files.
It sounds like you are looking to drop this support (I can't quite tell
as your patch was dropped by the mailing list). Instead it would be
better to see if we can change File.lastLastModifiedTime to use the
higher precision timestamp if possible. It will of course need to be
converted to millis.
-Alan
