On Thu, Oct 08, 2009 at 08:27:42PM +0000, Eric Blake wrote:
>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.
Why not send these type of musings to the cygwin-developers list? It really
is more appropriate for this type of discussion.
cgf
--
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
