8229280: Test failures on several linux hosts after JDK-8181493

[Brian Burkhalter]

> On Sep 1, 2019, at 1:16 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 29/08/2019 01:56, Brian Burkhalter wrote:
>> 
>> Done [1].
> The test description needs `@modules java.base/sun.nio.fs:+open` to open the package to the test. That should allow L42-50 to be cleaned up.

With the @modules tag as above compilation fails:

        // Check whether futimens() system call is supported
        Method futimensSupported =
            sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported");
        futimensSupported.setAccessible(true);
        if (!(boolean)futimensSupported.invoke(null)) {
            System.err.println
                ("futimens() system call not supported; skipping test");
            return;
        }

java/nio/file/attribute/BasicFileAttributeView/SetTimesNanos.java:45: error: UnixNativeDispatcher is not public in sun.nio.fs; cannot be accessed from outside package
            sun.nio.fs.UnixNativeDispatcher.class.getDeclaredMethod("futimensSupported");
                      ^
1 error

>> Note however that futimens() can be supported without it actually being able to set the timestamps to nanosecond precision, e.g., for HFS file systems on macOS. Therefore the test will still pass if the actual and expected values are not equal due to truncation of a multiple of three digits of precision.
> Is there any way that we could use the FileStore::type to target this test to specify file systems that are known to support nanosecond precision?

Sure. These types at least would work: apfs, ext4, xfs, zfs. That would get rid of ugly truncation checking.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190904/e37f90c4/attachment-0001.html>