New submission from Cotton Seed :
Seeking past the end of a file with file objects does not match the same code
implemented in terms of file descriptors. Is this the intended behavior?
Smallest example I could find:
f = open('new_file', 'ab')
print(f.seek(1))
print(f.write(b'foo'))
print(f.tell())
f.close()
This program outputs: 1, 3, 4 as expected, but only creates a 3-byte file:
and creates a 3-byte file:
$ hexdump -C new_file
66 6f 6f |foo|
0003
If I use open(..., buffering=0), or flush before the tell, it outputs: 1, 3, 3.
The obvious code with file descriptors:
fd = os.open('log', os.O_WRONLY | os.O_CREAT)
print(os.lseek(fd, 1, os.SEEK_SET))
os.write(fd, b'foo')
os.close(fd)
works as expected, creating a 4-byte file.
Could this be related this issue:
https://bugs.python.org/issue36411
?
--
components: IO
messages: 385692
nosy: cotton.seed
priority: normal
severity: normal
status: open
title: seeking past the end of a file unexpected behavior
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue43028>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
