This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients nadeem.vawda, neologix, pitrou, ronaldoussoren, santoso.wijaya, sdaoden, vstinner
Date 2011-07-18.17:26:29
SpamBayes Score 7.289558e-12
Marked as misclassified No
Message-id <1311009990.93.0.133179836732.issue11877@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-07-18 17:26:31neologixsetrecipients: + neologix, ronaldoussoren, pitrou, vstinner, nadeem.vawda, santoso.wijaya, sdaoden
2011-07-18 17:26:30neologixsetmessageid: <1311009990.93.0.133179836732.issue11877@psf.upfronthosting.co.za>
2011-07-18 17:26:30neologixlinkissue11877 messages
2011-07-18 17:26:29neologixcreate