file.tell problems (1.5.2/Win32)

[Gordon McMillan]

Holger Jannsen wrote:
> 
> Greg Ewing schrieb:
> > 
> > Joshua Rosen wrote:
> > >
> > > This leads me to believe that `append mode' is intended to `append' at the
> > > *current* point in the file, which should, for consistency's sake, start at 0.
> 
> I think there is the answer: "Some Unix-Systems" properly would
> append the write-string directly at the current file position. 
> 
> > I just tried an experiment (on Windows) using "a+"
> > mode. It seems that f.tell() is telling the truth,
> > but the truth is strange.
> > 
> > What "a"/"a+" modes seem to mean is "open the
> > file positioned at 0, but if the first operation
> > is a write, go to the end of file before doing
> 
> I think even this is `bizarre`!
> Because you could 1st work with "read(1)" or readline()
> on the file, getting correct fileposition (tell), but then a
> write even wouldn't work like expected!;-( It doesn't work!!
> Take the test:
> Create a small file with e.g. 3 lines a 10 characters.
> >>> f=open('test.txt','a+')
> >>> f.tell()
> 0
> >>> f.read(12)
> '111111111111'
> >>> f.write("sssss")
> >>> f.tell()
> 17
> >>> f.close()
> You won't even see the obviosly written string inside the file!! I
> think, here's something wrong!?
> 
> > it". Which seems quite bizarre to me - wouldn't
> > it be simpler to just go to the end of the
> > file on opening?

The MSVC help text says """\
When a file is opened with the "a" or "a+" access type, all write
operations occur at the end of the file. The file pointer can be
repositioned using fseek or rewind, but is always moved back to the
end of the file before any write operation is carried out. Thus,
existing data cannot be overwritten.
"""

This appears to say the same as the (Linux) man page for "open" when 
it discusses "O_APPEND". And the MSVC help text makes it clear that 
"a" and "a+" in fopen correspond to the use of "O_APPEND" in the 
flags to open.

The man page for "fopen" notes that """\
Note that ANSI C requires that a file poistioning function intervene 
between output and input, unless an input operation encounters 
end-of-file. (If this condition is not met, then a read is allowed to 
return the result of writes other than the most recent.)
""" 

But it never explicitly discusses whether writes can take place at 
anything other than end of file. I have only used "a+" when I wanted 
that behavior, and "r+" when trying to do something as you do above.

So the only deviation I detect in Windows behavior is that an ftell() 
on a just opened non-empty "a+" file returns 0 instead of 
end-of-file.

> You've seen: I could even read on a 'a+'-mode-opened file
> getting new file-position.
> And there are 'some Unix-OSs' that do the IMHO right thing to 
> append directly at the current file-position without jumping
> to the end of file.
> 
> Ciao,
> Holger
> [Python1.52, WinNT4.0]
> 
> -- 
> http://www.python.org/mailman/listinfo/python-list

- Gordon