How to bypass Windows 'cooking' the I/O? (One more time, please)

[Ulrich Eckhardt]

norseman wrote:
> In this case it's [MS Windows] (still) 'cooking' the writes even
> with 'rwb' and O_RDWR|O_BINARY in (proper respective) use.
> 
> Specific:  python created and inspected binary file ends:
> 00460: 0D 1A        (this is correct)

I'm not actually sure what the 0x1a is supposed to do there. The 0x0d is
a '\r' which looks like a MacOS line ending, but I also seem to remember
0x1a being use as EOF signal in some old system's text files. Anyway, you
mentioned some "binary file" (aren't they all?) so this might not matter
after all.

> after a write
> os.lseek(target, -1, 2)

That should be os.SEEK_END and not 2. In any case, it moves the write
position to the last byte (-1 offset to the end of the file).

> os.write(target,record)
> the expected result would be:
> 00460: 0D 20 .....data bytes.... 1A

I'm sorry, but I don't see that. write() will not insert the bytes but first
overwrite till EOF and then append further output, i.e. the 0x1a at the end
is only present if it was present in the record.

> BUT I get:
> 00460: 20 .... data bytes... 1A
> 
> It is one byte off!!!  And the 0D has to be there. Signifies the end of
> the header.

Okay, this looks strange, both the offset and the fact that it seems to
insert bytes. How about providing a minimal example?

> Anyway - if whoever mentioned the flags and such to 'over ride'
> Microsoft's BS would re-send that piece I would be very appreciative.

You are not one with the Tao, which is why you programs don't run. ;)

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932