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