Mike Kent wrote:
To followup on this:
Terry: Yes, I did in fact miss the 'buffer' parameter to open.
Setting the buffer parameter to 0 did in fact fix the test code that I
gave above, but oddly, did not fix my actual production code; it
continues to get the data as first read, rather than what is currently
on the disk. I'm still investigating why.
Some hardware, OS?
How do you know what is currently 'on disk'? Even with 'buffering'
turned off, the disk is read and written in 'blocks'. 512 bytes was
common on unix. I suspect it is larger on Linux now. (4k on Windows,
typically). You *might* be seeing something as deep as the driver for a
particular disk. Good luck.
Carl: I tried the above test code, without 'buffer=0' in the open, but
with a flush added before reads in the appropriate places. The flush
made no difference; readline continued to return the old data rather
than what was actually on the disk. So, flush isn't the answer. I
suppose that means that, when the document states it flushes the
buffer, it's referring to the output buffer, not the input buffer.
Yes, I checked C99 reference
--
http://mail.python.org/mailman/listinfo/python-list
