goto icon indicating copy to clipboard operation
goto copied to clipboard

gob data becomes unhappy after multiple runs of goto

Open nictuku opened this issue 13 years ago • 1 comments

store.gob is a file opened with O_APPEND for writes and gobs are appended to it. But it looks like this confuses the gob decoder after the first execution of the program. When it runs, it creates a gob Encoder object, and each new gob encoder will always include the type information into the file content. The result is redundant type definitions in the file. So the file will look like this:

.gob type defs .data .data <stop program, start again> .gob type defs .data .data

As a result, the decoder shows a warning (extra data in buffer) and interrupts the decoding.

One possible solution is to write to a different file in each execution, but read from all of them during load(). Or alternatively load() could decode the file in logical blocks, each using a separate Decoder object.

(I don't know if you had plans to update this tool, but even if you don't I thought it was worth documenting this issue anyway.)

nictuku avatar Apr 08 '11 18:04 nictuku

Unrelated comment:

Writes to store.gob are currently buffered in a Go buffer, and Flush() is called sometimes. Is this really needed? Linux already buffer filesystem writes, so you could get rid of the go buffer and write to the file directly - then instead of calling Flush(), you could call f.Sync() for the same purpose. (note that in the current code you miss a file Sync).

Cheers, Yves

(Again, I know goto was written for illustration purposes only, so I won't mind if you just ignore these issues.)

nictuku avatar Apr 08 '11 18:04 nictuku