IOError after normal write

[patrickgerken]

BPO	1252149
Nosy	@tim-one

^{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 2005-08-12.21:22:11.000>
created_at = <Date 2005-08-04.19:30:41.000>
labels = ['invalid', 'OS-windows']
title = 'IOError after normal write'
updated_at = <Date 2005-08-12.21:22:11.000>
user = 'https://bugs.python.org/patrickgerken'

bugs.python.org fields:

activity = <Date 2005-08-12.21:22:11.000>
actor = 'tim.peters'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2005-08-04.19:30:41.000>
creator = 'patrick_gerken'
dependencies = []
files = []
hgrepos = []
issue_num = 1252149
keywords = []
message_count = 4.0
messages = ['25991', '25992', '25993', '25994']
nosy_count = 2.0
nosy_names = ['tim.peters', 'patrick_gerken']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1252149'
versions = []

[patrickgerken]

After some Bughunting of Code with ConfigParser stuff
which worked under Linux and didn't under Windows, it
all boiled down to these three lines of codes:

fp = open('bla','w+'
fp.readline()
fp.write('bla')
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in ?
    fp.write('bla')
IOError: (0, 'Error')

The same test under linux is a success.

These teste have been run on the newest XP with
python 2.4.1.

[tim-one]

Logged In: YES
user_id=31435

Well, this is pilot error, inherited from the limitations of C I/O:
the effect of mixing reads with writes on a file open for update
is entirely undefined unless a file-positioning operation occurs
between them (for example, a seek()). I can't guess what
you expect to happen, but seems most likely that what you
intend could be obtained reliably by inserting

    fp.seek(fp.tell())

between your readline() and your write().

[patrickgerken]

Logged In: YES
user_id=1324112

I could not believe it and was searching for verification for this
for a long time. If somebody does not believe it like I did:
The C faq from usenet(Which I should have checked first...)
answers this question too, and delivers two references:
References: ANSI Sec. 4.9.5.3
ISO Sec. 7.9.5.3

[tim-one]

Logged In: YES
user_id=31435

It's not _necessary_ to design an I/O library this way, and the
Python docs aren't really clear about that Python's I/O
inherits the quirks of the platform C's I/O, so don't at all feel
bad about bringing it up. C libraries often exploit the latitude
allowed by the C standards here to increase efficiency
in "typical cases".