[issue30460] file opened for updating cannot write after read

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30460] file opened for updating cannot write after read

[Jeremy Kloth]

Jeremy Kloth added the comment:

It seems to me that it is a quite simple fix:

--- a/Objects/fileobject.c
+++ b/Objects/fileobject.c
@@ -1110,7 +1110,7 @@ file_read(PyFileObject *f, PyObject *args)
-clearerr(f->f_fp);
+if (ferror(f->f_fp)) clearerr(f->f_fp);

which is exactly what the empty read case does above this.

This fixes my error, and produces no changes to the test suite.

I guess it could be wrapped in an #ifdef MS_WINDOWS, just it case, but that 
seems unnecessary as the previous code does not.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30460] file opened for updating cannot write after read

[Eryk Sun]

Eryk Sun added the comment:

It might be simplest to close this as 3rd party since it's similar to 
bpo-29817. A workaround is to call f.seek(0, 1) to reset the stream state when 
switching between reading and writing. 

That said, a switch to writing at EOF should be supported. The problem is that 
Python 2's file_read function in fileobject.c executes the following code in 
this case:

if (bytesread < buffersize && !interrupted) {
clearerr(f->f_fp);
break;
}

clearerr() resets the EOF flag on the stream, so the Windows CRT has no way to 
know that it's allowed to reset the buffer from read-mode to write-mode in the 
subsequent write. Finally, Python raises a weird 'success' exception because 
the CRT writes fewer than the number of requested bytes without setting errno. 
AFAIK, this scenario only occurs on Windows. glibc on Linux appears to be more 
robust in this case.

A simple way to demonstrate this without involving a debugger is to add a 
second read() call before the write(). The 2nd read() takes a different path in 
file_read(), which doesn't clear the stream's EOF flag. 

import os, tempfile
fd, fn = tempfile.mkstemp()
os.write(fd, 'some text')
os.close(fd)
f = open(fn, 'r+')

>>> f.read()
'some text'
>>> f.read()
''
>>> f.write('more text')
>>> f.close()

>>> open(fn).read()
'some textmore text'

--
nosy: +eryksun
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30460] file opened for updating cannot write after read

[Jeremy Kloth]

New submission from Jeremy Kloth:

Attempting to append to an existing file fails with no error set:

>>> import os, tempfile
>>> fd, fn = tempfile.mkstemp()
>>> os.write(fd, 'some text')
9
>>> os.close(fd)
>>> with open(fn, 'r+') as f:
... f.read()
... f.write('more text')
... 
'some text'
Traceback (most recent call last):
  File "", line 3, in 
IOError: [Errno 0] Error

(error 0 is defined as NO_ERROR)

--
components: IO, Windows
messages: 294379
nosy: jkloth, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: file opened for updating cannot write after read
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com