WriteFile() whacks st_atime (was Re: stat() whacks st_atime)

[Jason Tishler]

On Fri, Jul 27, 2001 at 09:58:42AM -0400, Jason Tishler wrote:
> On Fri, Jul 27, 2001 at 10:21:09AM +1000, Robert Collins wrote:
> > My guess would be it's the file header reading logic - looking for
> > #!/bin/foo
> > 
> > that means that a file access _has occured_. CloseHandle triggering the
> > actual write might jsut eb a win32 optimisation, to only wr
> 
> Bingo!  Thanks for helping me to see what I was missing in my haste.  I
> guess that the solution is to starting using ntsec (which I should be
> doing for other reasons too).

After converting to ntsec, the above problem has been corrected.
Unfortunately, I was still having problems with st_atime getting set
unexpectedly.

I finally found the root cause, WriteFile().  However Microsoft
obfuscated this fact by documenting it in the MSDN entries for
GetFileTime()/SetFileTime() instead of WriteFile():

lpLastAccessTime 
    Pointer to a FILETIME structure that contains the date and time the
    file was last accessed. The last access time includes the last time
    the file was written to, read from, or (in the case of executable
                 ^^^^^^^
    files) run.  This parameter can be NULL if the application does not
    need to set this information.

The first attachment, wtest4.c, demonstrates that the problem due is to
Win32 and not Cygwin.

The second attachment is a "patch" (I'm using the term very loosely)
that works around this Windows-ism so that Cygwin behaves Posix-like
with regard to write() and st_atime.

Does a cleaned up version of this patch have a chance of being accepted?
I'm concerned about race conditions, performance impact, affecting
non-disk files, etc.  Is this simplistic approach the best way to work
around the problem?  Or, are there better ways?

Thanks,
Jason