[Python-Dev] Why do we flush before truncating? (original) (raw)

Guido van Rossum guido at python.org
Sat Sep 6 21:55:46 EDT 2003

Ack, I glossed over the fileno() call in our filetruncate(). It's usually a Very Bad Idea to mix stream I/O and lower-level I/O operations without flushing your pants off, but I'm having a hard time thinking of a specific reason for doing so in the truncate case. Better safe than trying to out-think all possible implementations, though!

I think the fflush() is there for the following case: a file is opened for update, some data is written that overwrites some bytes in the middle but not yet flushed, and then the file is truncated to that position. Since ftruncate works on the file descriptor, you'd want the data flushed before truncating, otherwise things just get too complicated.

I suppose that clarifies my immediately preceding

>> ftruncate() isn't a standard C function, ?

I somehow misread what you wrote as "is a standard C function".

> I just realize that I have always worked under the assumption that > fflush() after a read is a no-op; I just checked the 89 std and it > says it is undefined. (I must have picked up that misunderstanding > from some platform-specific man page.) This can be fixed by doing a > ftell() followed by an fseek() call; this is required to flush the > buffer if there was unwritten output data in the buffer, and is always > allowed.

That's what I was hoping to avoid, but I don't care anymore: after staring it some more, I'm convinced that the current filetruncate() endures a ridiculous amount of complexity trying to gain a tiny bit of speed in what has to be a rare operation.

Right.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list