In the most recent checkout on Linux, test_largefile.py fails. The output is:
[guido@pcp742651pcs linux]$ ./python ../Lib/test/test_largefile.py create large file via seek (may be sparse file) ... check file size with os.fstat 2500000001L =?= 2500000001L ... yes check file size with os.stat 2500000001L =?= 2500000001L ... yes play around with seek() and read() with the built largefile 0L =?= 0 ... yes 'z' =?= 'z' ... yes 1L =?= 1 ... yes 0L =?= 0 ... yes 0L =?= 0 ... yes 42L =?= 42 ... yes 42L =?= 42 ... yes 84L =?= 84 ... yes 84L =?= 84 ... yes 2500000001L =?= 2500000001L ... yes 2499999991L =?= 2499999991L ... yes 0L =?= 0 ... yes 2500000000L =?= 2500000000L ... yes 'a' =?= 'a' ... yes 'z' =?= 'z' ... yes 1L =?= 1 ... yes play around with os.lseek() with the built largefile 0L =?= 0 ... yes 42L =?= 42 ... yes 84L =?= 84 ... yes 84L =?= 84 ... yes 2500000001L =?= 2500000001L ... yes 2499999991L =?= 2499999991L ... yes 0L =?= 0 ... yes 2500000000L =?= 2500000000L ... yes 'a' =?= 'a' ... yes try truncate 2500000001L =?= 2500000001L ... yes 2499999990L =?= 2499999990L ... yes 2499999990L =?= 2499999990L ... yes 0L =?= 2499999989L ... no Traceback (most recent call last): File "../Lib/test/test_largefile.py", line 149, in ? expect(f.tell(), newsize) File "../Lib/test/test_largefile.py", line 59, in expect raise test_support.TestFailed, 'got %r, but expected %r' %\ test_support.TestFailed: got 0L, but expected 2499999989L [guido@pcp742651pcs linux]$
--Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
In the most recent checkout on Linux, test_largefile.py fails. The output is:
[guido@pcp742651pcs linux]$ ./python ../Lib/test/test_largefile.py ... try truncate 2500000001L =?= 2500000001L ... yes 2499999990L =?= 2499999990L ... yes 2499999990L =?= 2499999990L ... yes 0L =?= 2499999989L ... no
The docs promise something that may not be true, and the test (which was commented out before yesterday) assumes something that may not be true:
1. The docs promise that truncate() will never grow the file. I don't believe Unix ftruncate() promises that, although you got beyond the part of the test that checks for that (so ftruncate apparently won't grow the file on your box).
2. The test assumes truncate() leaves the file position at the point of truncation. That's why your test is failing:
# Ensure that truncate(smaller than true size) shrinks the file. newsize -= 1 f.seek(0) f.truncate(newsize) expect(f.tell(), newsize) # ***** you're failing here *****
The output shows that, on your box, the file position was left at 0. Our docs are silent on this point.
If we want to promise that truncate() won't grow the file, I believe the non-Windows implementation needs to change.
If we don't want to promise that truncate() won't grow the file, the docs need to change and the Windows implementation can be made simpler.
If we want to promise that the file position won't change, the docs need to change, Unix geeks have to investigate the truth of that on non-Windows systems, and the Windows implementation needs to change.
Tim> 1. The docs promise that truncate() will never grow the file. I Tim> don't believe Unix ftruncate() promises that...
It does not. In fact, on my Mandrake box it explicitly says that behavior is unspecified:
If the file previously was shorter, it is unspecified whether the file is left unchanged or is extended.
Skip
-
Guido van Rossum -
Skip Montanaro -
Tim Peters