Re: utimensat round 3

[Jim Meyering]

Eric Blake wrote:

> According to Jim Meyering on 10/16/2009 6:34 AM:
>>>> This failure may also be due to the way utimecmp works,
>>>> but I haven't delved into that code today.
>>> So yes, I'm starting to think we need to teach utimecmp about
>>> quantization, and declare two mtimes as equal if they would both quantize
>>> to the same value (even if they have distinct values due to higher
>>> resolution).  But how to determine quantization of a given filesystem?
>>
>> I wouldn't worry about that right now (or maybe ever ;-).
>> Short term, I'd change the test so it exercises UTIME_NOW,
>> but keeping st1 and st2 far enough apart that sub-second
>> effects aren't an issue.
>> Then there's no need for UTIMECMP_TRUNCATE_SOURCE.
>
> Well, from your output, your system had a quantization at 10ms when done
> by the system, so a usleep(20000) should be enough.  I've worked that into
> my test, as shown below, and pushed the series.  Please try it to see if
> it solved that particular failure for you.  At least for me on cygwin, it
> was enough of a workaround to bypass cygwin's clock_gettime drift as well.

...
> Subject: [PATCH] test-stat-time, test-utimens: improve portability
>
> ext4 on an alpha system has a quantization of about 10 ms but

Thanks.  That solved it for me.
FYI, that was "Fedora 12 alpha (as in pre-release)" not alpha-the-CPU.
My CPU happened to be an x86_64.