The test driver (and ZODB) use buffered I/O, not unbuffered POSIX I/O. Assuring that writes done to buffered streams are visible to other processes is trickier than Martin's reliance on the write(2) man page, since write(2) isn't involved in the chain.
All you need to do is call f.flush(). This calls write(2) internally (even on Windows).
Sorry, I don't understand the point of this Unixish chest-puffing <0.8 wink>.
POSIX doesn't mandate that fflush() call write(), although it requires, as an extension to the C standard, pretty much the same end result.
Nevertheless, calling f.flush() isn't enough on Windows, regardless of whether the native Windows Python or Cygwin Python is doing it. Without the os.fsync(f.fileno()) too, native Windows utilities and the Windows Python see a wrong current file size. This gets pretty bizarre too: after letting Cygwin Python write and flush a million bytes (i.e., at the first prompt in the test driver), the Cygwin Python (in a different process) os.path.getsize() returns a million, but the Windows Python returns 0. Put in the fsync too and everyone is happy. This can't work if fsynch goes missing in the Cygwin Python.