Fix inconsistent behavior of java.nio.file.attribute.BasicFileAttributes.lastModifiedTime()

[Schaef, Martin]

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" <Alan.Bateman at oracle.com> 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