>   One could argue that something had happened before the fsync(2),
>   so that code which blindly did so is too dumb to do any right
>   decision anyway.  Even PEP 3151 won't help.

I don't understand. If the syscall supposed to flush the disk's buffer
cache fails - be it fcntl() or sync_file_range() - I think the error
should be propagated, not silently ignored and replaced with another
syscall which doesn't have the same semantic. That's all.

> - I favour haypos fullsync() approach, because that could probably
>   make it into it.  Yet Python doesn't offer any possibility to
>   access NetBSD DISKSYNC stuff sofar.

Are you willing to update your patch accordingly?

> - Currently the programmer must be aware of any platform specific
>   problems.  I, for example, am not aware of Windows.  How can
>   i give any guarantee to users which (will) use my S-Postman on
>   Windows?  I need to put trust in turn into the Framework i am
>   using - Python.  And that makes me feel pretty breathless.

I agree.

> - Fortunately Python is dynamic, so that one simply can replace
>   os.fsync().  Works once only though (think signal handlers :=).

Yes, but since it's a fairly reasonable and useful feature, I think it
could be merged.

>   + Aaarrg!  I'm a liar!!  I lie about - data integrity!!!

Well, actually, some hard disks lie about this too :-)