RFR: 8343417: (fs) BasicFileAttributeView.setTimes uses microsecond precision with NOFOLLOW_LINKS [v2]
Brian Burkhalter
bpb at openjdk.org
Wed Nov 6 03:13:34 UTC 2024
On Tue, 5 Nov 2024 20:05:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java line 88:
>>
>>> 86: useLutimes = lutimesSupported();
>>> 87: }
>>> 88: if (!useUtimensat && !useLutimes) {
>>
>> Changing the utimesat method to match the sys call is good. Now I wonder if we go further and use fd from openForAttribtueAccess(false) with utimesat. That would remove the window between the lstat and utimesat(AT_FDCWD...) where the file may be replaced.
>
> Indeed UnixFileAttributes.get calls lstat. Calling symlink.openForAttributeAccess(false) however yields
>
> java.nio.file.FileSystemException: symlink: No such file or directory or unable to access attributes of symbolic link
>
> According to [symlink(7)](https://www.man7.org/linux/man-pages/man7/symlink.7.html):
>
> The last access and last modification timestamps of a symbolic link can be changed using utimensat(2) or lutimes(3).
>
> It looks like futimens will not work with a symlink's fd so that utimensat is necessary here to obtain nsec precision. I don't see a way to close the window between lstat and utimensat, which anyway was already there for the lutimes case.
I don't think that the logic in 08f5b7d is quite correct yet. It might be possible if followLinks is false and the file is not a symlink, that lutimes would be used even though futimens is supported, thus decreasing the timestamp resolution.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21886#discussion_r1830334196
More information about the nio-dev
mailing list