Mail Archives: djgpp/1998/05/07/10:19:35
In article <Pine DOT SUN DOT 3 DOT 91 DOT 980504162902 DOT 25049B-100000 AT is>, Eli Zaretskii
<eliz AT is DOT elta DOT co DOT il> 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
- Raw text -