[issue11877] Change os.fsync() to support physical backing store syncs

Charles-François Natali report at bugs.python.org
Mon Jul 18 19:26:30 CEST 2011


Charles-François Natali <neologix at free.fr> added the comment:

Trying to revive this issue, here's a comment I left on Rietveld:

"""
> I don't agree, the documentation states that full_sync will cause a flush to
> stable storage where supported and a plain fsync where it isn't. This code
does
> just that.
>

I think I wasn't clear enough, so let me rephrase: the call to fcntl is guarded
by #ifdef, so it is only called on platforms where it is supported, otherwise
fsync() is called. What I was referring to is the fact that an fsync is tried if
the call to fcntl fails with ENOTTY: if I ask my operating system to flush disk
buffers and it can't, then I'd rather have an error returned, so that I can take
the right decision (abort, roll-back, try a classical fsync). IMHO, silently
masking an error by falling back to another syscall is wrong.
"""

Anyway, I think this patch can be useful (see for example issue #8604 as a typical use case). I personally don't care since I use Linux, but OS-X and *BSD folks might find some interest in this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11877>
_______________________________________


More information about the Python-bugs-list mailing list