Hi Andreas.

> By the VM. The support code opens all writable files so that further
> attempts to open this file in write mode are denied. Note that this is
> currently a Very Good Idea - here is why:
> 
> StandardFileStream>>flush
>         "In some OS's seeking to 0 and back will do a flush"
>         | p |
>         p _ self position.
>         self position: 0; position: p

Ahhhhhhhhh... sheesh... one would think that telling the OS to seek...
but you tell the OS to seek a file, not the file to seek... this looks
very complex without an accompanying reason... indeed, it looks as if
the Mac OS is using some sort of read ahead buffer shared with the write
buffer...

"Ooh, tacky, very tacky." -- Tim Rowledge

This also looks like hard drives... some will move the heads when told
to seek, and some others won't move the heads until they are told to
move data... of course after this was done, all the seek speed tests on
the lazy disks reported 0ms, ummmmmm...

> The comment is really a wild, wild guess - I'm assuming that the above
> actually works on Macs but on Windows seeking to zero means nothing at all
> in terms of flushing the stream (and I very much believe the same for any
> Unix variant). We will definitely need a flush primitive for file streams
> before you can even think about using multiple streams on the same file.

I hope Tim's fix candidate makes it easier to accomplish this.

Andres.