This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Fix truncate on Windows, this time for real
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.0
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: christian.heimes, gvanrossum, nnorwitz
Priority: normal Keywords: patch

Created on 2007-10-26 01:39 by christian.heimes, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
py3k_win_io.patch christian.heimes, 2007-10-26 01:39
py3k_win_io2.patch christian.heimes, 2007-10-26 04:44
Messages (4)
msg56769 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 01:39
The patch fixes for real what "Patch # 1323 by Amaury Forgeot d'Arc"
claims to have fixed. I reverted his patch to io.py and implemented the
fix in the Windows specific part of truncate in _fileio.c. It fixes two
tests for raw io on Windows.
msg56776 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-26 04:13
While I like fixing the position restore in _fileio.c, I also liked
Amaury's flush() call in _BufferedIOMixin.  Perhaps you can keep that
part (while losing the position restore)?
msg56778 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-10-26 04:44
> While I like fixing the position restore in _fileio.c, I also liked
> Amaury's flush() call in _BufferedIOMixin.  Perhaps you can keep that
> part (while losing the position restore)?

Good point. We have to call flush() in _BufferedIOMixin as you said. I
checked if I could add a flush call to _fileio but it makes no sense. We
are working on file descriptors which means we don't have to use
fflush() and FileIO's flush() is a NOOP.
msg56797 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-10-26 17:21
Committed revision 58673.

I made one change, hopefully I didn't screw it up: skip the positional
restore if the truncation itself failed.  Otherwise the positional
restore might overwrite the error from the truncation.  After an error
from this function they shouldn't make any assumptions about the
position anyway!
History
Date User Action Args
2022-04-11 14:56:27adminsetgithub: 45671
2008-01-06 22:29:45adminsetkeywords: - py3k
versions: Python 3.0
2007-10-26 17:21:45gvanrossumsetstatus: open -> closed
resolution: accepted
messages: + msg56797
2007-10-26 04:44:55christian.heimessetfiles: + py3k_win_io2.patch
messages: + msg56778
2007-10-26 04:13:51gvanrossumsetmessages: + msg56776
2007-10-26 03:19:07gvanrossumsetkeywords: + py3k, patch
assignee: gvanrossum
2007-10-26 01:40:15christian.heimessetnosy: + gvanrossum, nnorwitz
2007-10-26 01:39:31christian.heimescreate