Dennis Lee Bieber wrote:
On Mon, 07 Jul 2008 01:03:10 -0700, norseman <no******@hughes.net>=============================================
declaimed the following in comp.lang.python:
I wouldn't expect that sequence to work on any system... The "w"> >
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.
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><eofmark (which isn't a normal Windows sequence anyway --
since Windows uses <cr><lffor 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 no******@hughes.net
