qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v


From: Hidetoshi Seto
Subject: Re: [Qemu-devel] Re: [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2
Date: Mon, 15 Nov 2010 11:10:37 +0900
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6

(2010/11/14 14:58), Chris Wright wrote:
> * Hidetoshi Seto (address@hidden) 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]