-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zip file format details #12
Comments
Either:
The latter is often used in streaming scenarios. zipzap has some streaming and non-streaming scenarios, but for cleanness of implementation, I always treat them as streaming.
This is tricky and is really up to the quality of the unarchiver. I've based zipzap off the algorithm expressed in minizip, which has a fair amount of history to it.
This search is complicated by the possibility that a perverse archiver could write out a second etc. EndOfCentralDirectory header in the variable length comment. Because of this (and performance reasons), zipzap does a backward search and only uses the last header it finds. It could be argued that this is incorrect, since this is not a "real" header but a variable length comment. But I chose an algorithm that will work even with a perverse archiver, not necessarily one that will work correctly in such a situation. Some refinements I did think of
Some other unarchivers do a search forward from the start of the zip. This has several issues:
|
Wow, it is quite tricky then! It occurs to me that unarchivers can take different strategies depending on the task at hand. For example, if the end goal is to decompress an archive, then there's no harm in searching through the data, decompressing as you go, to find the data descriptors. Also for situations where compressed data sizes are already known, zipzap could potentially be kind to unarchivers and generate local file headers that contain the file size. Thank you for filling me in. |
…fixes-11 to develop * commit '068f2b6a8c65f4abda0d1fd6f837c56ad38a7b13': ULYSSES-3444 Fixes a crash when using a defective list format string
I originally posted this as part of another issue, as I was working my way through the reasoning for it in order to come to a final conclusion. Split out here as requested though:
OK, so first of all, let me make sure I've understood the layout of a zip file:
The apparent duplication of
LocalFileHeader
andDataDescriptor
strikes me as weird. From poking around zip archives I have here, it looks likeLocalFileHeader
generally reports file sizes to be0
. So I'm guessing unarchivers take that as a signal to consult theDataDescriptor
for the true size of the file? Thus allowing a file to be rewritten into the archive without yet knowing the size it will be when compressed.And then by waiting until the end of the archive to note the extra info associate with it, that also simplifies generation.
The bit I don't understand though, how do unarchivers know how to find the individual files and
CentralFileHeader
if eachLocalFileHeader
claims its data is of zero length?ZZDataDescriptor.signature
. If so, how do you avoid hitting false positives inside of the compressed data?CentralFileHeader
contains knowledge of each file's length/location, and be consulted to work back and find the files. But if so, how do you find the central header itself?!The text was updated successfully, but these errors were encountered: