From: Paul Shirley Newsgroups: comp.os.msdos.djgpp Subject: Re: Make "Clock Skew" problem. Date: Wed, 6 May 1998 17:33:10 +0100 Organization: wot? me? Message-ID: <8m5Z6AAGDJU1Ew4k@foobar.co.uk> References: NNTP-Posting-Host: chocolat.foobar.co.uk Mime-Version: 1.0 Lines: 29 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In article , Eli Zaretskii writes >> Wild guess: perhaps the time is set according to when the cache is >> flushed to disk, rather than when the data was actually written by the >> program? > >I thought about this, but I find this hard to believe. The test program >used to gather data about this runs these checks in a tight loop, >typically many times a second, so the file time is checked long before the >cache is flushed (if that delay is indeed 2 seconds). I've just investigated a related problem (in W95JED) where files get marked as modified-on-disk wrongly. It appears that W95 updates the last-modified-time during the delay between flushing the file and vcache actually handling it. I'm seeing a time difference of .36 seconds between the time returned on closing a file and that returned later. Whilst it does not directly explain the make future time problem, it does indicate that windoze timestamps really are screwed. A tightly looping test program may not be waiting long enough to see the timestamp change. I'm also seeing a 1-2 second difference between the creation and modification times on these files which strongly suggests that win95 is using the time of flushing from cache rather than the real write time. Given the primitive filesystem/network that's probably the correct thing to do on a networked machine ;) --- Paul Shirley: my email address is 'obvious'ly anti-spammed