Date: Tue, 29 Aug 2000 08:52:20 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Peter J. Farley III" cc: djgpp AT delorie DOT com Subject: Re: Q: libc fstat: Why is st_ctime < st_atime == st_mtime after fopen? In-Reply-To: <39ab3cee.32395153@news3.banet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.