(2010/11/14 14:58), Chris Wright wrote: > * 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).
Thank you for comments! I'll post an updated one soon. Thanks, H.Seto