On Aug 7, 2008, at 12:36 AM, Ian Charnas wrote: > Hello heroes and heroins of the python universe, lend me your ears and > I will tell you a tale that will make your platters spin! > > As noted by SQLite [1] and MySQL [2] developers, fsync on OS X does > not actually flush a file to disk... instead OS X provides "fullfsync" > which actually flushes the file descriptor to disk. This simple patch > modifies python's "fsync" to take advantage of fullfsync on platforms > that support it: > http://bugs.python.org/issue3512 > > While some people might suggest that fullfsync should be exposed as a > method on the 'os' module for platforms that support it, I believe > this is not the best approach. Because the docstring for os.fsync > says that it forces the file to be written to disk, I think it's up to > python to ensure that functionality is really there on all platforms. > Currently on OS X, fullfsync is needed to provide this functionality, > so I think python's os.fsync should use fullfsync on OS X. Please don't make that change. fsync on OSX does the same thing as fsync traditionally does on other OSes. That is: it flushes the data to "disk", but doesn't make any effort to ensure that the disk drive actually flushes the data from its own write cache to the platter. Other OSes just don't expose that functionality *at all*. See e.g. this thread: http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html You should instead propose a patch to add F_FULLSYNC to the fcntl module when present. James
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4