Buffered I/O does not take file position into account when reading blocks

[ericpruitt]

BPO	24666
Nosy	@pitrou, @vstinner, @benjaminp

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-10-22.17:30:57.024>
created_at = <Date 2015-07-19.05:00:46.021>
labels = ['type-bug', 'invalid', 'expert-IO']
title = 'Buffered I/O does not take file position into account when reading blocks'
updated_at = <Date 2021-10-22.17:30:57.023>
user = 'https://bugs.python.org/ericpruitt'

bugs.python.org fields:

activity = <Date 2021-10-22.17:30:57.023>
actor = 'iritkatriel'
assignee = 'none'
closed = True
closed_date = <Date 2021-10-22.17:30:57.024>
closer = 'iritkatriel'
components = ['IO']
creation = <Date 2015-07-19.05:00:46.021>
creator = 'ericpruitt'
dependencies = []
files = []
hgrepos = []
issue_num = 24666
keywords = []
message_count = 2.0
messages = ['246931', '404801']
nosy_count = 5.0
nosy_names = ['pitrou', 'vstinner', 'benjamin.peterson', 'stutzbach', 'ericpruitt']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24666'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3', 'Python 3.4']

[ericpruitt]

When buffering data from a file, the buffered I/O does not take into account the current file descriptor position. In the following example, I open a file and seek forward 1,000 bytes:

>>> f = open("test-file", "rb")
>>> f.seek(1000)
1000
>>> f.readline()

The filesystem on which "test-file" resides has a block size of 4,096 bytes, so on the backend, I would expect Python to read 3,096 bytes so the next read will be aligned with the filesystem blocks. What actually happens is that Python reads a 4,096 bytes. This is the output from an strace attached to the interpreter above:

Process 16543 attached
lseek(4, 0, SEEK_CUR) = 0
lseek(4, 1000, SEEK_SET) = 1000
read(4, "\000\000\000\000\000\000\000\000\000\000"..., 4096) = 4096