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.
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.