Message9692

Author santa4nt
Recipients fwierzbicki, santa4nt, tuck182, zyasoft
Date 2015-03-21.02:15:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1426904140.5.0.0314386932085.issue1793@psf.upfronthosting.co.za>
In-reply-to
Content
Huh. Looks like this is caused by optimization in the way we buffer file read operations. fd.read(1) does not strictly read only one byte from the underlying java.nio.channels.FileChannel object.

Jython's fd.read() (where fd is returned by file() built-in function) is dispatched to PyFile#file_read method. Eventually, the read operation is done by calling FileChannel#read(ByteBuffer[] dsts) scattered IO read where the first byte buffer is the one returned to the caller (in this case of size 1), but there exists a secondary byte buffer that will be filled with the rest of the file.

So in the case of the test case above, when we're at, say, position 253 and call fd.read(1), we'll get the 254th byte as read, but the underlying file channel has been read all the way to the end. Hence, fd.seek(-1, SEEK_CUR) having the surprising result.
History
Date User Action Args
2015-03-21 02:15:40santa4ntsetmessageid: <1426904140.5.0.0314386932085.issue1793@psf.upfronthosting.co.za>
2015-03-21 02:15:40santa4ntsetrecipients: + santa4nt, fwierzbicki, zyasoft, tuck182
2015-03-21 02:15:40santa4ntlinkissue1793 messages
2015-03-21 02:15:39santa4ntcreate