On Wed, Apr 20, 2011 at 12:16:39PM +0000, Ronald Oussoren wrote:
> This is the same behavior as fsync on OSX, and OSX also has
> a second API that provides stronger guarantees.
> With your patch it is no longer possible to call the C function
> fsync on OSX, even though it is good enough for a lot of use
> cases. As os.fcntl already supports F_FULLSYNC I see no good
> reason to change the implementation of os.fsync on OSX.

I don't see it that way for multiple reasons.

One of it is that Python states that it "is a beginner language",
and the sentence i've quoted a part of in my last message is very
beginner friendly.  Now i don't think you can require that much
further knowledge from a beginner at all than what is described in
that very sentence.

(Just think of an african kid with a sponsored laptop and possibly
10 minutes internet access per day which tries hard to rise up and
puts *galaxies of trust* in what it reads in os.rst, maybe because
it is the only documentation he has available!)

Then Python is a high-level language.  It's true that there are
many shallow wrappers around lower-level functions, but still.
It is cross-platform.  Just have a look into a, say, file I/O
implementation of a C library/program which aims to be portable.
If all that #if#endif would be necessary in a high-level language,
then why don't write a Makefile and compile that thing?
Not that much more work, then - many thanks to the GCC people!
You know - i wouldn't talk about subtleties of filesystems here.

And then - at least half a dozen of programmers with altogether
maybe many decades of experience, full-time internet access
(talking about you :) required two months to get around the Apple
bug.  A simple "man 2 fsync" would have sufficed for a starter!
And how ridiculous - i've spend the free time of four days :-(
It's a shame, it's a bug, i wouldn't it let pass through to users.

Apple?  No, i'm looking forward to return to a private BSD/Linux
X/ahwm/aterm/vim laptop.