(2010/11/14 14:58), Chris Wright wrote:
> * Hidetoshi Seto (seto.hidetoshi@xxxxxxxxxxxxxx) 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
