OK I finished a patch that exposes os.fullfsync on platforms that support it, and I added the corresponding documentation in Doc/library/os.rst
Any comments? http://bugs.python.org/issue3517 -ian On Thu, Aug 7, 2008 at 10:17 AM, Ian Charnas <[EMAIL PROTECTED]> wrote: > Excellent comments, everyone. It looks like I didn't know the full > situation, thanks scott for pointing me towards that email on > darwin-dev. The email said that fsync on OS X does indeed force a > flush from the operating system to the hard drive (so my earlier > understanding was incorrect), but data could still be waiting in the > write buffer of the physical hard drive, so OS X provides a > "fullfsync" feature to force the disk to flush its buffers. So far > they are seemingly the only unix to provide this. > > So, I think we should cancel the ticket I made in Roundup, and I'd > like to make another patch that exposes os.fullfsync on platforms that > support it, just like we already have os.fdatasync on supported > platforms. > > That way, os.fsync remains untouched, and people wishing to get at > fullfsync may do so. > > comments? Should I go ahead and make this patch? > > many thanks, > -Ian Charnas > > On Thu, Aug 7, 2008 at 9:48 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >>> I can't think of a situation where it would be useful to do an fsync() >>> in which you don't want the data to be flushed as far as possible. >> >> Essentially, you are saying that you don't see a use for fsync. If >> that's the case, then this API should be removed from Python completely. >> >> As all others have said: the strong feature of the posix module is that >> it exposes the operating system calls *as-is*, i.e. without trying to >> tweak their semantics. >> >> If Apple had found it as a useful default for fsync to have the >> harddisk flushed, they would have put that into the implementation >> of fsync, instead of coming up with a new API. We don't second-guess >> operating system vendors (normally). >> >> Please understand the enormous relevance of this strategy. If we >> deviate from it, people might be stuck in chasing the culprit, >> complaining alternatingly to the OS vendor and to Python. With our >> strategy to the POSIX module, we can always defer people to the >> system vendor, and they can easily reproduce the behavior with >> a C program. (Of course, we also have higher-layer libbraries, were >> any bugs are our own). >> >> Regards, >> Martin >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ian.charnas%40gmail.com >> > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com