* Hidetoshi Seto (seto.hideto...@jp.fujitsu.com) wrote:
> + /*
> + * Fallback: use utimes() instead of utimensat().
> + * See commit 74bc02b2d2272dc88fb98d43e631eb154717f517 for known problem.
> + */
> + struct timeval tv[2];
> + int i;
> +
> + for (i = 0; i < 2; i++) {
> + if (times[i].tv_nsec == UTIME_OMIT || times[i].tv_nsec == UTIME_NOW)
> {
> + tv[i].tv_sec = 0;
> + tv[i].tv_usec = 0;
I don't think this is accurate in either case. It will set the
atime, mtime, or both to 0.
For UTIME_NOW (in both) we'd simply pass NULL to utimes(2). For
UTIME_OMIT (in both) we'd simply skip the call to utimes(2) altogether.
The harder part is a mixed mode (i.e. the truncate fix mentioned in the
above commit). I think the only way to handle UTIME_NOW in one is to
call gettimeofday (or clock_gettime for better resolution) to find out
what current time is. And for UTIME_OMIT call stat to find out what the
current setting is and reset to that value. Both of those cases can
possibly zero out the extra precision (providing only seconds
resolution).
thanks,
-chris
