RFR: 8338884: java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 [v6]

[Severin Gehwolf]

On Tue, 3 Sep 2024 13:05:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use jni to determine the tested file support birth time or not

Changes requested by sgehwolf (Reviewer).

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35:

> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
> 34:     return statx_func != NULL ? JNI_TRUE : JNI_FALSE;
> 35: #else

This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in.

See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00

Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2277769847
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1742258338