Date:	Tue, 30 Jun 1998 10:14:36 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: Windows 9X/NT file times
In-Reply-To:	<m0yqjBg-000S2iC@inti.gov.ar>
Message-ID:	<Pine.SUN.3.91.980630101424.6274F-100000@is>
MIME-Version:	1.0

On Mon, 29 Jun 1998, Salvador Eduardo Tropea (SET) wrote:

> Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> 
> > Here's a sample output from my version of Windows 95:
> > 
> >      Statistics:   	   average           min              max
> >    -----------------------------------------------------------------------
> >    Creation time   	     +203msec	       +0msec	   +1.200sec
> >    Last-access time	+16514.577sec	-71144.000sec	-71131.000sec
> >    Last-write time 	     -997msec	   -1.989sec	      -49msec
> 
> And here is one from v4.00.1111:
> 
>   Statistics:   	   average           min              max
> -----------------------------------------------------------------------
> Creation time   	       +0msec	       +0msec	      +30msec
> Last-access time	-13895.720sec	-57727.000sec	-57716.000sec
> Last-write time 	     +956msec	       +0msec	   +1.981sec

Thanks, this is indeed a significant difference between our two
Windows versions.  Based on these results, I would suspect that they
have just added 2 seconds to the last-write time stamps (possibly to
prevent last-write time from being *before* creation time, which looks
silly).

It also seems that they've made the creation time be much more
accurate than in the previous version of Windows: the spread of
differences against the system clock is much less in your case.

One wonders why did they work that hard on making creation time
accurate and leave the modification time with the 2-second
granularity.  Can somebody imagine a program that should care about
creation time so much more than about the last modification time?

> Don't know why ever positive because you are sampling the time
> *after* the operation. Perhaps is related to the Windows cache
> architecture. Perhaps they are using some write delay (like in UNIX)
> instead of cache but M$ didn't take care about the time thing.

I don't think this is related to the disk cache at all.  To see that,
you can tell the program to instruct Windows to flush the buffers
associated with the file the program opens, each time the file is
written to, like this:

	 w32time 100 0x4002

On my system, this didn't have any effect except that it significantly
slowed down the program.  It would be interesting to see if it has any
effect on other versions of Windows.

Theoretically at least, disk cache should have no effect whatsoever on
the file time stamps, or else it will wreak havoc.  Typically the
cache flushes its buffers using system calls which are below the
file-oriented functions (e.g., it writes sectors, not files), so the
file times aren't affected by this flushing.  It seems that the
Windows cache behaves correctly at least in this regard.

Thanks again for helping me gather data.

- Raw text -