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