[Martin v. Löwis]
I mostly agree: ZODB is indeed advanced, and it is indeed a good idea to check for presence of os.fsync before using it.
While this is OT, I'd still like to question the usefulness of fsync(2) in the first place, for applications like ZODB. I assume fsync is used as a write barrier, to make sure old modifications are on disk, before making new changes.
That's important, but not primarily for the catastrophic error-recovery scenarios you go on to sketch.
Tim, trust me. The scenario you go on to sketch is unique to Windows.
fsync() was invented on Unix. On that platform, there's *never* a need to do fsync() to allow another process to see the right data. fsync()'s effect is just not visible at the abstraction level presented by the kernel. fsync() is needed because sometimes (e.g. through a power or kernel failure) the kernel's abstraction is broken. Everybody except you who is arguing for fsync()'s importance does so because they have experienced (or fear to experience) crashes.
It's a bug in the Windows implementation of Unix-style I/O that a commit() call (which is what fsync() is aliased to in posixmodule.c on Windows) is needed in order to ensure that other processes see what a process wrote.
Given that fsync() on Windows doesn't have the configuration problem that started all this, I'm not sure how *your* argument for fsync() can help convince Martin that we should do a 2.3.2 release ASAP.
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)