by sanderhahn:
go version go1.3.1 darwin/amd64
The zip api doesn't allow creating a zip file with a different offset than zero. This is
relevant for instance if a zip file is appended to an existing binary. The reader reads
the zip contents alright but only when the offsets are first corrected using the
"zip -A" command.
I understand this is not a high priority issue, but it would be nice to have a pure go
way of creating zips at an offset other than zero. For instance if you want to embed
files into your own binary.
The solution that i see that would not break the existing API is providing an additional
construtor that takes the initial count value for the countWriter:
// writer.go
func NewWriterAt(w io.Writer, count int64) *Writer {
return &Writer{cw: &countWriter{w: bufio.NewWriter(w), count: count}}
}
Another solution would be to make the zip reader smarter and automatically correct the
offsets if they are not correct (as the unzip tool does).
Is it possible to consider this additional constructor in a new release?
An example program that uses a patched version of the stdlib zip to add zip contents to
an existing binary is at: https://github.com/sanderhahn/gozip
Thank you for the great language and tooling :)
Best regards,
Sander Hahn
by sanderhahn:
go version go1.3.1 darwin/amd64 The zip api doesn't allow creating a zip file with a different offset than zero. This is relevant for instance if a zip file is appended to an existing binary. The reader reads the zip contents alright but only when the offsets are first corrected using the "zip -A" command. I understand this is not a high priority issue, but it would be nice to have a pure go way of creating zips at an offset other than zero. For instance if you want to embed files into your own binary. The solution that i see that would not break the existing API is providing an additional construtor that takes the initial count value for the countWriter: // writer.go func NewWriterAt(w io.Writer, count int64) *Writer { return &Writer{cw: &countWriter{w: bufio.NewWriter(w), count: count}} } Another solution would be to make the zip reader smarter and automatically correct the offsets if they are not correct (as the unzip tool does). Is it possible to consider this additional constructor in a new release? An example program that uses a patched version of the stdlib zip to add zip contents to an existing binary is at: https://github.com/sanderhahn/gozip Thank you for the great language and tooling :) Best regards, Sander Hahn