This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

utimensat UTIME_NOW granularity bug

The gnulib test for utimensat found a bug in utimensat: it truncates time too 
much, and has the result of making time appear to flow backwards.

This sample code sequence shows the problem (when run at speed; of course 
single stepping this introduces delays and masks the problem):

close (creat ("file", 0600));
stat ("file", &st1);
utimensat (AT_FDCWD, "file", NULL, 0);
stat ("file", &st1);

(gdb) p st1.st_mtim 
$3 = {tv_sec = 1255024956, tv_nsec = 526817600}
(gdb) p st2.st_mtim
$4 = {tv_sec = 1255024956, tv_nsec = 526817000}

Windows expresses time as a fraction, rounded to a quanta with significant 
digits out to a 10th of a microsecond (even though the quanta at which time 
observably advances is much larger than that), but utimensat is currently 
rounding to the nearest microsecond.  The result is that the timestamp set 
during Windows events (such as close) is recorded with more resolution than 
what happens for utimensat, such that consecutive instructions appear to run 
out of order.

I think we need to implement a companion to systime(), which returns the system 
time without any truncation, so that the function clock_gettime(CLOCK_REALTIME) 
can report time with resolution to the 10th of a microsecond rather than to 
plain microseconds.  Then utimensat needs to use clock_gettime rather than 
gettimeofday, so that it is not needlessly truncating the 10th of microsecond 
resolution available from Windows.

Eric Blake

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]