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 sdaoden
Recipients nadeem.vawda, neologix, pitrou, ronaldoussoren, santoso.wijaya, sdaoden, vstinner
Date 2011-05-17.13:49:32
SpamBayes Score 2.9224057e-09
Marked as misclassified No
Message-id <20110517134922.GA31090@sherwood.local>
In-reply-to
Content
Thank you, thank you, thank you.
I'm a bit irritated that a french man treats a "wet-her" as a typo!
What if *i* like it??  In fact it is a fantastic physical backing
store.  Unbeatable.

Well and about dropping the fsync() in case the fcntl() fails with
ENOTTY.  This is "<Esc>2dd", which shouldn't hurt a committer.
I'm convinced that full_fsync=False is optional and false by
default, but i don't trust Apple.  I've seen a reference to an
"atomic file" somewhere on bugs.python.org and that does fsync()
first followed by fcntl() if FULLFSYNC is available.  Thus, if
someone knows about that, she may do so, but otherwise i would
guess he doesn't, and in that case i would not expect ENOTTY from
an fsync() - still i want a full flush!
This is what NetBSD describes:

NOTES
    For optimal efficiency, the fsync_range() call requires that
    the file system containing the file referenced by fd support
    partial synchronization of file data.  For file systems which
    do not support partial synchronization, the entire file will
    be synchronized and the call will be the equivalent of calling
    fsync().

But Apple is *soooo*speeeeciaaaal* again.  Happy birthday.
History
Date User Action Args
2011-05-17 13:49:34sdaodensetrecipients: + sdaoden, ronaldoussoren, pitrou, vstinner, nadeem.vawda, neologix, santoso.wijaya
2011-05-17 13:49:33sdaodenlinkissue11877 messages
2011-05-17 13:49:32sdaodencreate