Trouble with file.seek/file.tell on Win32?

[Prabhu Ramachandran]

Hi,

Many thanks for taking the time to respond.

>>>>> "TP" == Tim Peters <tim.peters at gmail.com> writes:

    TP> [Prabhu Ramachandran]
    >> I noticed peculiar behavior under Python-2.3.4 under Win32.
    >> When I run something like this:
    >>
    >> f = open('t.txt', 'wb') f.write('1\012'+'2\012'+'3\012')
    >> f.close() f = open('t.txt', 'r')

    TP> Sorry, you're in trouble already.  You can *tell* Windows
    TP> that's a text file, but it doesn't contain native Windows
    TP> text-file data (it has the wrong kind of line end for
    TP> Windows).

Yes, I was aware of that, files with the right line endings did work
fine.  I was not aware that files with the wrong line endings under
Win32 could break tell and seek.

Here is what happened.  I was building a self-extracting installer for
a CVS snapshot of MayaVi (using Gordon McMillan's installer).  The
file in question is a MayaVi visualization file.  This is parsed to
generate a visualization.  I use file.tell and file.seek to handle
some backwards compatibility issues (its an ugly hack but works).

The file in question has not changed in years and used to work fine
when I built the installer last time.  What I did not realize is that
the file that is distributed with the previous installer had the right
line endings!  Here is the wierd part.  I work primarily on Linux and
build a zip and tarball using distutils.  I take the zip file to a
windows box and have setup scripts to do bulk of the dirty work.  It
has worked just fine in all previous attempts (on different machines
with earlier versions of Python).  This time I setup a Windows XP
machine with all the software.  I got the ZIP file I just built,
unzipped it, and tried to load the example visualization and it
failed.  For some reason the line endings were not converted this time
around.  I had no explanation as to why that happened.  I suspected
that it was the line endings under windows.  Since neither the files
or *my* scripts had changed in any way to touch line endings, I
suspected it was a bug with the way Python handled the line endings
this time.  It was not distutils either since the MayaVi-1.3.zip file
at sourceforge also has the unix style file.  So I assumed that since
nothing relevant had changed with my sources and scripts it must be
Python.  I was wrong.

I now realize that the only significant difference is the unzip
utility I used.  I used Winzip the last time I built the binaries.  A
google search reveals that Winzip does indeed convert line endings by
default.  This time I used the standard WinXP tools to unzip the file
and they don't convert line endings.  I did not know or suspect that.
So, sorry for the false alarm.  I'm happy though that the puzzle is
solved.  I'm happy to also learn that bad line endings break tell and
seek.  I guess this is a problem on the mac too where lines end with
'\r'.  Is this true of OSX?

Anyway, it looks like I should either simply read and write to the
file using the 'rb' and 'wb' modes on all platforms or make sure that
line endings in the file are correct on the platform.  I should also
encourage folks to use unzip utilities with care.

[...]

Thanks for the detailed example showing that the problem is not with
Python.  Sorry for the bother.

Thanks again.

regards,
prabhu