>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.

Logged In: YES 
user_id=31435

Repaired, via

Lib/test/test_file.py; new revision: 1.13
Misc/NEWS; new revision: 1.852
Objects/fileobject.c; new revision: 2.182