Mail Archives: djgpp/2000/08/29/01:53:31
On Tue, 29 Aug 2000, Peter J. Farley III wrote:
> st_ctime < st_atime == st_mtime
>
> For example, the test program produced this output when I just ran it:
>
> atime=967508974,ctime=967508972,mtime=967508974
>
> On first glance, I would have thought that all these values would be
> equal right after an "open for output" on a new file. If there is a
> reason they are not, I would appreciate knowing why.
There *is* a reason, if you regard Windows bugs and misfeatures to be a
valid reason ;-).
This is a known problem with all versions of Windows 9X and NT (I don't
know what happens with W2K and ME, but I'm guessing the problem is there
as well). The situation is actually much worse than what you describe;
for the gory details and some test programs and results see the thread
started by this message:
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/1998/06/29/13:09:04
> The test program mirrors perl code that is failing in testing a DJGPP
> build of perl-5.6.0, which expects that ctime == mtime unless the
> system is Cygwin or Win32 (but makes no exception for DJGPP).
The DJGPP version needs a special treatment as well. Careful testing
demonstrates that ctime might be behind mtime and the system clock by as
much as 3 seconds(!). The port of GNU Make was printing spurious
warnings about clock time skew until such a change was introduced there
(that's how I first learned about this problem).
My guess is that Windows does all those crazy things because ctime has a
100-nanosecond granularity, while mtime has a 2-second granularity. So
they wanted to prevent the situation where ctime is later than mtime, but
their solution sucks, as always.
- Raw text -