Issue 801631: file.truncate fault on windows (original) (raw)

manual says file.truncate leave the pointer unmoved,

f=file('test.dat', 'wb') to make things easier f.write('1234567890') f.close() f=file('test.dat','rb+') f.read(5) '12345' f.tell() 5L f.truncate() f.tell() 10L

( PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32. )

Seems it's a Windows only bug. On a 2.4.3 linux, libc-2.2.5 the final statement produces 5L (and the file is only 5 bytes long). Same on another 2.4.19 libc-2.2.5, and a 2.4.21 libc-2.3.1 Linux, all with a recent Python 2.4a0 .
reproduce on Windows.

Logged In: YES user_id=31435

Oh, fudge. The Windows code here is trying very hard to preserve the file position, but it turns out that C fflush() on Windows changes the file position in this specific test case.

However, the C standard says (about fflush):

""" If stream points to an output stream or an update stream in which the most recent operation was not input, the fflush function causes any unwritten data for that stream to be delivered to the host environment to be written to the file; otherwise, the behavior is undefined. """

The last operation performed by the test program before Python's internals call fflush() was an input operation, so the effect of calling fflush() is undefined. If it varies across platforms (as appears to be the case here), that's fine by the standard, and Python is relying on undefined behavior.

If you stick, e.g., f.seek(5) after the f.tell() call, then on Windows this test program works as intended (prints 5 at the end, and the file is truncated to 5 bytes). Then the last operation performed on the stream opened for update is not an input operation, so the effect of fflush() is defined.