Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
archive/zip: io.Reader like archive/tar #10568
What exactly do you want? Are you suggesting that NewReader (or a variant of that) should take an io.Reader instead of an io.ReaderAt? That's impossible to do, as to read a zip file, you have to read the directory at the end, without that information, you don't even know whether each file is compressed or not.
Impossible? Here's a java snippet (of the critical code) from an installer I wrote years ago, which reads large zip files, and displays images from near the start of the archive while the rest of it downloads.
URLConnection connection = new URL(updateZipURL).openConnection();
API for ZipInputStream here: https://docs.oracle.com/javase/7/docs/api/java/util/zip/ZipInputStream.html
To answer your first question, I want to port the installer to go. I also have another project that would benefit from this library.
Of course it won't work in the general case.
zipinfo c.zip or unzip c.zip will only show the good_stuff, however, a streaming
In general, zip file can have arbitrary prefixed data at the front, how could a
I like your example. It shows the care and thoughtfulness that goes into the standard library. The javadoc makes no mention of how false positives are caught (probably aren't) or should be handled.
To deal with arbitrary prefixed data, one could return errors from the Next function:
FirstNFilesInvalidError: could be used to catch cases where files were prepended without directory record. Technically this error could/should be used for the above case as well.
Alternatively/Additionally, one could have explanations/warnings of streaming zips in the docs.
Yeah, the feature does make sense for certain applications where you can trust the content to be the "normal" zip files, so implementing it as a go-gettable package would be great (I think you can reuse a lot of the code in the package). But for the standard archive/zip package, I think we'd better not introduce non-general interfaces that might have security issues if used improperly. Thanks. PS: if your installer unzip file directly from http/https, you use use one of the range request adapters (search godoc or golang-nuts) that turns any idempotent http response into seekable stream and then use the standard archive/zip. As long as you extract strictly according to the order in the zip file, I don't think the performance will be that bad (basically it will first seek to the end, read the central directories and then go back to the beginning and extract files.)