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.
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().
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
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".
