On 8/14/07, Matthew Scott  wrote:
> Executing this line on OSX resulted in result == ''.  However,
> executing it on WinXP resulted in result == '\x00' * 24


Furthermore, when I restarted and stopped at the same place, and did
an "eval len(f.read())", that returned 4056, which is interestingly
4096 - 40, or 2 ** 12 - 40.

I'm wondering what could be causing the file object to think that
there are 4096 null bytes...

Well, I found out something interesting just now.  On WinXP:

Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f = file('foo.test', 'w+b')
>>> len(f.read())
0
>>> f.write(' ')
>>> len(f.read())
4095
>>> len(f.read())
0
>>> f.write(' ')
>>> len(f.read())
4095
>>> len(f.read())
0

It appears that whenever you write to a file (in 'w+b' mode at least),
Windows pads it to the size of a block of the filesystem, or at least
it seems that way.

However, if you flush the file first, the results are more sane:

>>> f = file('foo.test', 'w+b')
>>> len(f.read())
0
>>> f.write(' ')
>>> f.flush()
>>> len(f.read())
0

I think this is enough information for me to make a patch now.  Cross
your fingers :)


--
Matthew R. Scott
If my mail is terse, see http://five.sentenc.es/