Guido van Rossum wrote:
> If I understand the post properly, it's up to the app to call fsync(),
> and it's only necessary when you're doing one of the rename dances, or
> updating a file in place. Basically, as he explains, fsync() is a very
> heavyweight operation; I'm against calling it by default anywhere.
I agree with you, fsync() shouldn't be called by default. I didn't plan
on adding fsync() calls all over our code. However I like to suggest a
file.sync() method and a synced flag for files to make the job of
application developers easier.
When a file is opened for writing and has the synced flag set, fsync()
is called immediately before the FILE *fp is closed.
Suggested syntax:
>>> f = open("somefile", "ws")
>>> f.synced
True
or:
>>> f = open(somefile, "w")
>>> f.synced
False
>>> f.synced = True
>>> f.synced
True
The sync() method of a file object flushes the internal buffer(fflush()
for Python 2's file object) and fsync() the file descriptor.
Finally the documentation should give the user a hint that close() does
not necessarily mean the data is written to disk. It's not our
responsibility to teach Python users how to deal with low level stuff.
On the other hand a short warning doesn't hurt us and may help Python
users to write better programs.
For the rest I concur with MvL and AMK.
_______________________________________________
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
