On Tue, Mar 10, 2009 at 7:45 PM, Christian Heimes <li...@cheimes.de> wrote:
> Antoine Pitrou wrote:
>> Christian Heimes <lists <at> cheimes.de> writes:
>>> 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.
>>
>> We already have os.fsync() and os.fdatasync(). Should the sync() (and
>> datasync()?) method be added as an object-oriented convenience?
>
> It's more than an object oriented convenience. fsync() takes a file
> descriptor as argument. Therefore I assume fsync() only syncs the data
> to disk that was written to the file descriptor. [*] In Python 2.x we
> are using a FILE* based stream. In Python 3.x we have our own buffered
> writer class.
>
> In order to write all data to disk the FILE* stream must be flushed
> first before fsync() is called:
>
> PyFileObject *f;
> if (fflush(f->f_fp) != 0) {
> /* report error */
> }
> if (fsync(fileno(f->f_fp)) != 0) {
> /* report error */
> }
Let's not think too Unix-specific. If we add such an API it should do
something on Windows too -- the app shouldn't have to test for the
presence of the API. (And thus the API probably shouldn't be called
fsync.)
> Christian
>
> [*] Is my assumption correct, anybody?
It seems to be, at least it's ambiguous.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
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
