[cvsnt] Re: wnt_fclose and FlushFileBuffers

[Tony Hoyle]

John Goehringer wrote:

> Tony,
> 
>     I'm seeing poor performance on both the client and server
> with build 69 compared to build 68 and tracked it down to
> the FlushFileBuffers call in win32.c:wnt_fclose.
> 
>     Was this for AtomicCommits support? Perhaps
> 
No, it's to work around a bug in NT.

Basically, when you call CloseHandle, it doesn't actually close the handle,
it just asks to OS nicely to do it when it gets around to it.  This can
randomly cause the MoveFileEx that happens about 100th of a second later to
fail with a locked file.  On fast machines you won't notice it, but testing
on a slow machine caused failure in a significant number of cases.  Atomic
commits make it worse, making the whole thing unusable even on the
relatively fast machines I work with.

I actually had to do a fair bit of mucking around with RCS to get it to
close its files earlier to get anything to work at all with atomic commits
enabled.  Until I can work out how to get NT to actually close files when I
tell it the final flush is a good safety measure...  

The speed seems to be comparable... nothing really noticeable on the size of
repositories I've been using with it.

Tony