Mail Archives: cygwin/2009/10/08/16:28:28
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: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -