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

[norseman]

Dennis Lee Bieber wrote:
> On Mon, 07 Jul 2008 01:03:10 -0700, norseman <norseman at hughes.net>
> declaimed the following in comp.lang.python:
> 
>>  >
>>  > Normal file I/O sequence:
>>  >
>>  > fp = open(target, 'wb')
>>  >
>>  > fp.seek(-1, 2)
>>  >
>>  > fp.write(record)
>>  >
>>
>>    Except it doesn't do that in Windows. See below.
>>
> 	I wouldn't expect that sequence to work on any system... The "w"
> implies "create new file, or truncate existing file to 0-bytes, then
> write data to it" -- with no seeking permitted. You must include the "+"
> to do seeking, and if you want to retain the existing file contents you
> probably need to open with "a+" ("a" for append).
> 
> 	The rest of your situation I won't touch. Other than to wonder why
> the situation hasn't hit any of the various database servers which must
> be operating in binary mode, and perform lots of seeking... Surely
> somewhere out someone else must have encountered a seek crossing an
> apparent <cr><eof> mark (which isn't a normal Windows sequence anyway --
> since Windows uses <cr><lf> for EOL, I'd have expected to see a problem
> if backing over a <cr><lf><eof>)
=============================================
"I wouldn't expect..."  ABSOLUTELY CORRECT. No append because the hex-1A
has to be overwritten. (use r+b) There can be only one of those and it
has to be the last byte of the file. The hex-0D at the beginning of a 32
BYTE segment signifies end of structure definition. The hex-1A double
checks the record count. (standard Ashton-Tate dBASE file)
If someone wants to check it out, appending the hex-1A to each record
and backing up one byte on each write reduces coding complexity and
machine cycles considerably.

"The rest of..."   I have seen the answer posted but can't find it. I'm
hoping someone has it, sees this and posts the original solution again.
Or knows how to set things to bypass the nonsense and posts that.

Steve norseman at hughes.net