为什么touch包含utimensat（）系统调用？

Question

Looking into an odd time sequencing of file mtimes, I noticed that the (gnu) touch command includes an utimensat syscall as part of its touch sequence:

open("touchedLater", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
dup2(3, 0)                              = 0
close(3)                                = 0
dup2(0, 0)                              = 0
utimensat(0, NULL, NULL, 0)             = 0
close(0)                                = 0

It appears that the touch command explicitly zeros the subsecond portion of the files' timestamp. Other methods of file creation don't necessarily do this, and in clearcase V8 dynamic views, this is causing "interesting" sequencing issues with make.

Why would touch zero the subsecond modification time for the file using this utimensat syscall?

EDIT: dg99 points out that this API, as called in the way that strace indicates may be an attempt to set the time to the current time, not clear the subsecond portion of the time, as observed. In an attempt to repro this, I tried a call to utimensat (fd, NULL, NULL, 0), but this produces an EINVAL. It turns out that strace is lying (perhaps slightly: maybe the same kernel syscall does both utimensat and futimens APIs), and what touch.c is actually doing is:

269               result = futimens (fd, ts);
(gdb) s
272               if (0 < result)
(gdb) p fd
$4 = 0
(gdb) p ts
$5 = (struct timespec *) 0x0

Calling some standalone code in this fashion, using futimes also has the appearance of clearing the subsecond portion of the time using using clearcase version 8 MVFS.

Answer 1

From my reading of the utimensat man page, the above call is not explicitly setting anything to zero, but rather is setting both access and modification timestamps to the current time:

 int utimensat(int dirfd, const char *pathname, const struct timespec times[2], int flags); 

... the new file timestamps are specified in the array times ... If times is NULL, then both timestamps are set to the current time.