Re: utimensat round 3

[Jim Meyering]

Eric Blake wrote:
> According to Jim Meyering on 10/16/2009 5:56 AM:
>> Note however, that test-utimens is failing for me
>> on an ext4 + Fedora-12-alpha-based system due to this:
>>
>>     /* See comment above about this utimecmp call.  */
>>     ASSERT (0 <= utimecmp (BASE "file", &st2, &st1, 
>> UTIMECMP_TRUNCATE_SOURCE));
>
> Aaargh.  And I also saw a failure on Solaris 9 + NFS on test-futimens, for
> the same reason that Solaris 8 was failing test-utimens.
>
>> That utimecmp assertion fails almost all the time due to the
>> comparison of two time stamps independently down-sampled
>> at different resolutions.
>>
>> It wasn't clear right away to me, so I wrote a program to
>> call clock_gettime, then utimensat-to-set-to-NOW, then stat.
>> Compare the clock_gettime result with st_mtime second and nanosecond values.
>>
>> I see ~1-millisecond-resolution FS timestamps
>> and higher-resolution clock_gettime times:
>
> Similar to what I'm seeing on cygwin - the default system clock is
> documented online as being about 15.25 milliseconds (more like 1/64
> second), but can be reduced as low as 1 millisecond.  All timestamps
> created by Windows use the default system clock, even though Windows also
> provides an API with more resolution (100 nanoseconds) and closer accuracy
> (depending on processor speed, can detect increments as small as a couple
> of microseconds).  So it creates the same situation - practically any
> timestamp created using clock_gettime will appear newer than the
> corresponding timestamp created by a system event, even though both would
> quantize to the same value.  But utimecmp is only worrying about
> resolution, not quantization.
>
>> 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.