Calling apr_file_flush on an unbuffered file is a no-op in the Unix and OS/2 implementations, however on Windows it is a call to FileFlushBuffers which can be an incredibly expensive call. I ran into this when the Windows build of log4cxx was 100-fold slower when writing to file than the Linux build. I've worked around the problem in log4cxx, however this seems like a landmine to catch unsuspecting developers. As it currently stands, apr_file_flush on Win32 leaves the buffered and unbuffered files in different states. If buffered, it flushes the APR maintained buffer but doesn't flush the OS buffer by calling FileFlushBuffers.
Committed, and backported for the next 0.9 and 1.2 releases.