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.

Author jasujm
Recipients jasujm
Date 2013-05-14.15:10:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
In-reply-to
Content
file.write doesn't sometimes raise IOError when it should, e.g. writing to /dev/full in line buffered mode:

jaakko@jm-laptop:~$ python
Python 2.7.5+ (2.7:a32a3b79f5e8, May 14 2013, 14:20:11) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f=open('/dev/full','w',1)
>>> f.write('hello\n')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 28] No space left on device
>>> f.close()
>>> f=open('/dev/full','w',1)
>>> f.write('hello')
>>> f.write('\n')
>>> f.close()
>>> # No IOError!
... 
>>> 

The current implementation of file.write relies on comparing the return value of fwrite to the expected number of bytes written to detect errors. I haven't dug deep enough into the C standard to know for sure if fwrite return value == expected should always imply no error, but in my example it clearly doesn't (I assume my glibc and fwrite aren't broken though). However using ferror to detect the error works fine and IOError was raised as expected.

Python3 and io module use different implementation where this is no longer an issue. For us still using Python 2.7 I suggest the attached simple patch to fix the issue.
History
Date User Action Args
2013-05-14 15:10:27jasujmsetrecipients: + jasujm
2013-05-14 15:10:27jasujmsetmessageid: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za>
2013-05-14 15:10:27jasujmlinkissue17976 messages
2013-05-14 15:10:26jasujmcreate