看看文件mtimes的奇怪时间sorting，我注意到（gnu） touch命令包含utimensat系统调用作为其触摸序列的一部分：
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
看起来，touch命令明确地将文件时间戳的亚秒部分置零。 其他文件创build方法并不一定这样做，而在清晰的V8dynamic视图中，这会导致“有趣”的sorting问题。
为什么会使用这个utimensat系统调用接触到零的文件的亚秒修改时间？
编辑：dg99指出，这个API，以strace指示的方式调用可能是尝试将时间设置为当前时间，不清除时间的亚秒部分，如观察到的。 在试图utimensat这个，我试着调用utimensat （fd，NULL，NULL，0），但是这产生了一个EINVAL。 事实certificate，strace正在撒谎（也许稍微：可能是同一个内核系统调用都会执行utimensat和futimens API），touch.c实际上是在做什么：
269 result = futimens (fd, ts); (gdb) s 272 if (0 < result) (gdb) p fd $4 = 0 (gdb) p ts $5 = (struct timespec *) 0x0
以这种方式调用一些独立代码，使用futimes也具有使用clearcase版本8 MVFS清除时间的亚秒部分的外观。
从我读的utimensat手册页，上面的调用没有明确设置任何零，而是设置访问和修改时间戳到当前时间：
int utimensat(int dirfd, const char *pathname, const struct timespec times[2], int flags);…新的文件时间戳是在数组时间中指定的…如果时间为NULL，则两个时间戳均设置为当前时间。