[Python-Dev] Re: RELEASED Python 2.3.1

[Tim Peters]

[Guido]
> Tim, trust me.  The scenario you go on to sketch is unique to Windows.

I would rather trust the test program, but I don't see much point to the
argument (if that's what this is):  if os.fsync has gone missing on
platforms that "used to" support it, of course that's a serious regression.

> 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.

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.

> Given that fsync() on Windows doesn't have the configuration problem
> that started all this,

I don't know whether Cygwin Python suffers the same problem.  If it does,
then people running ZODB under Cygwin 2.3.1 (which I don't believe has been
released yet) are in for nasty surprises if they run repozo.py under the
"native" Windows Python.  I've tried this under Cygwin 2.2.2 (see other
email).  Since that did have os.fsync(), but the native Windows Python
didn't at that time, my best guess is that Cygwin Python is affected.

> I'm not sure how *your* argument for fsync() can help convince Martin
> that we should do a 2.3.2 release ASAP.

It's enough for me that a function that used to be there has gone away
without good reason.  It's easier to cut a new release than argue about how
much trouble the missing os.fsync should cause, as people have already
poured more energy into complaining about it than would be needed to cut a
new release.