diff options
| author | Tim Peters <tim.peters@gmail.com> | 2003-09-07 03:30:18 (GMT) |
|---|---|---|
| committer | Tim Peters <tim.peters@gmail.com> | 2003-09-07 03:30:18 (GMT) |
| commit | f1827cfaab46e4d9137fd72543c83977eba50cb0 (patch) | |
| tree | a9eff73415e1950bd2448402d3d2db842d66cad0 /Misc | |
| parent | a26c16c821461986e08ddd63a60da42150180606 (diff) | |
| download | cpython-f1827cfaab46e4d9137fd72543c83977eba50cb0.zip cpython-f1827cfaab46e4d9137fd72543c83977eba50cb0.tar.gz cpython-f1827cfaab46e4d9137fd72543c83977eba50cb0.tar.bz2 | |
SF bug 801631: file.truncate fault on windows.
file_truncate(): C doesn't define what fflush(fp) does if fp is open
for update, and the preceding I/O operation on fp was input. On Windows,
fflush() actually changes the current file position then. Because
Windows doesn't support ftruncate() directly, this not only caused
Python's file.truncate() to change the file position (contra our docs),
it also caused the file not to change size.
Repaired by getting the initial file position at the start, restoring
it at the end, and tossing all the complicated micro-efficiency checks
trying to avoid "provably unnecessary" seeks. file.truncate() can't
be a frequent operation, and seeking to the current file position has
got to be cheap anyway.
Bugfix candidate.
Diffstat (limited to 'Misc')
| -rw-r--r-- | Misc/NEWS | 4 |
1 files changed, 4 insertions, 0 deletions
@@ -94,6 +94,10 @@ Tests Windows ------- +- file.truncate() could misbehave if the file was open for update + (modes r+, rb+, w+, wb+), and the most recent file operation before + the truncate() call was an input operation. SF bug 801631. + Mac ---- |