[issue4841] io's close() not handling errors correctly

Changes by Hynek Schlawack : -- stage: commit review -> committed/rejected status: open -> closed ___ Python tracker ___ ___ Python-bug

[issue4841] io's close() not handling errors correctly

Hynek Schlawack added the comment: I’ve committed due to haypo's wish on IRC. ;) -- resolution: -> fixed ___ Python tracker ___ ___ P

[issue4841] io's close() not handling errors correctly

Roundup Robot added the comment: New changeset 83d500908ffc by Hynek Schlawack in branch '2.7': #4841: Fix FileIO constructor to honor closefd when called repeatedly http://hg.python.org/cpython/rev/83d500908ffc New changeset 8a58670048c9 by Hynek Schlawack in branch '3.2': #4841: Fix FileIO co

[issue4841] io's close() not handling errors correctly

Antoine Pitrou added the comment: Hynek, no obvious reason, it probably slipped through :) -- ___ Python tracker ___ ___ Python-bugs-l

[issue4841] io's close() not handling errors correctly

Hynek Schlawack added the comment: The reasoning is reasonable, the patch trivial & LGTM, the test suite passes. Anything I’m missing, why this is still open? -- stage: patch review -> commit review ___ Python tracker

[issue4841] io's close() not handling errors correctly

Changes by Hynek Schlawack : -- nosy: +hynek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4841] io's close() not handling errors correctly

Changes by Meador Inge : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: Status of this issue: - io.FileIO.close() raises IOError with Python 2.7, 3.1, 3.2 and 3.3 (e.g. if the underlying file descriptor has been closed), it doesn't with Python 2.6 - If FileIO constructor is called twice, the file is closed at the second call eve

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: fileio_close.patch should maybe use os.open() (to create the fd) and os.fstat() (to check that the fd is not closed). -- ___ Python tracker ___

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: fileio_close.patch (for Python 3.3): Fix FileIO.__init__() to not close the file if closefd=False and the constructor is called twice (or more). -- Added file: http://bugs.python.org/file22417/fileio_close.patch ___

[issue4841] io's close() not handling errors correctly

Changes by Terry J. Reedy : -- versions: -Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue4841] io's close() not handling errors correctly

Changes by Brian Curtin : -- status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue4841] io's close() not handling errors correctly

Mark Lawrence added the comment: Might as well close as nobody appears interested. -- status: open -> pending ___ Python tracker ___ _

[issue4841] io's close() not handling errors correctly

Mark Lawrence added the comment: Please note the comment from Victor:- "Python 3.x is also affected by this issue: file_init() and dircheck() ignore self->closefd." -- nosy: +BreamoreBoy versions: +Python 3.1, Python 3.2 -Python 2.6 ___ Python track

[issue4841] io's close() not handling errors correctly

Ulrich Eckhardt added the comment: >> 4. I wonder if internal_close() should reset only the 'fd' field >> or if it should also reset 'readable', 'writable', 'seekable' > > seekable(), readable() and writable() raise an error if the file > is closed. I think it's fine to leave the internal attrib

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: > 1. The handling of the error in internal_close() isn't really good. What > I'm also not sure about is whether it is correct to set the error there, > the old code sometimes did set an error as reaction to internal_close() > failing and sometimes not. internal

[issue4841] io's close() not handling errors correctly

Ulrich Eckhardt added the comment: I have a patch here which passes the proposed change to the tests in trunk. A few notes up front though, since the patch isn't good yet: 1. The handling of the error in internal_close() isn't really good. What I'm also not sure about is whether it is correct t

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: In Python 3.x, internal_close() returns -1 on error (if close() returns a negative value) and 0 on success. In Python 2.x, internal_closes() returns the errno value of close() on error, or 0 on success. fileio_close() tests if the error value is negative ins

[issue4841] io's close() not handling errors correctly

Changes by STINNER Victor : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python

[issue4841] io's close() not handling errors correctly

STINNER Victor added the comment: In Python 3.x, internal_close() returns -1 on error (close() returns a negative value) and 0 on success. It tests if close() returns a negative In Python 2.x, internal_closes() returns the errno value of close() on error, or 0 on success. fileio_close() test

[issue4841] io's close() not handling errors correctly

Antoine Pitrou added the comment: Strangely enough, it works in py3k. -- nosy: +pitrou priority: -> critical stage: -> needs patch ___ Python tracker ___ __

[issue4841] io's close() not handling errors correctly

Ulrich Eckhardt added the comment: This adds a test that the close() correctly fails with an IOError. -- keywords: +patch Added file: http://bugs.python.org/file12593/python-2.7-fileio-close-test.0.patch ___ Python tracker

[issue4841] io's close() not handling errors correctly

New submission from Ulrich Eckhardt : In _fileio.c, there is the following comment: "Returns 0 on success, errno (which is < 0) on failure." The problem here is the claim that errno ever was less than zero, which is simply wrong. You can see this being a problem with the following few lines: im