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 erik.bray
Recipients erik.bray
Date 2013-12-27.23:33:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>
In-reply-to
Content
In #18876 I pointed out the following issue:

BufferedWriter/Random doesn't know the raw file was opened with O_APPEND so the writes it shows in the buffer differ from what will actually end up in the file.  For example:

>>> f = open('test', 'wb')
>>> f.write(b'testest')
7
>>> f.close()
>>> f = open('test', 'ab+')
>>> f.tell()
7
>>> f.write(b'A')
1
>>> f.seek(0)
0
>>> f.read()
b'testestA'
>>> f.seek(0)
0
>>> f.read(1)
b't'
>>> f.write(b'B')
1
>>> f.seek(0)
0
>>> f.read()
b'tBstestA'
>>> f.flush()
>>> f.seek(0)
0
>>> f.read()
b'testestAB'

In this example, I read 1 byte from the beginning of the file, then write one byte.  Because of O_APPEND, the effect of the write() call on the raw file is to append, regardless of where BufferedWriter seeks it to first.  But before the f.flush() call f.read() just shows what's in the buffer which is not what will actually be written to the file.  (Naturally, unbuffered io does not have this particular problem.)


Now that #18876 we can test if a file was opened in append mode and correct for this.  The attach patch includes a pretty simple solution that manually calls buffered_seek at the beginning of bufferedwriter_write if the raw file is in append mode.  In doing so it made sense to split buffered_seek into two separate functions.

This might be overkill, however.
History
Date User Action Args
2013-12-27 23:33:13erik.braysetrecipients: + erik.bray
2013-12-27 23:33:12erik.braysetmessageid: <1388187192.84.0.682821163597.issue20082@psf.upfronthosting.co.za>
2013-12-27 23:33:12erik.braylinkissue20082 messages
2013-12-27 23:33:12erik.braycreate