Skip to content
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

Support zip archives not starting at zero offset #346

Merged
merged 4 commits into from
Jul 21, 2024

Conversation

LemonBoy
Copy link
Contributor

Zip archives are usually read from the back to the front, making it possible to append them to other files (e.g. executables) in order to provide some kind of embedded filesystem.

This PR makes it possible to read, write, and update such zip files without affecting the existing functionality.

What's not possible is to append an archive to an arbitrary non-zip file.
The w switch should be able to do so, but at the moment the documentation states 'w': creates an empty file for writing. without rewinding the stream. I'd amend the documentation and make that mode create a brand new zip archive using the stream cursor as starting offset.
Would that be ok?

Once the w issue is sorted some tests can be easily written.

Zip archives are usually read from the back to the front, making it
possible to append them to other files (e.g. executables) in order to
provide some kind of embedded filesystem.

This PR makes it possible to read, write, and update such zip files
without affecting the existing functionality.
@kuba--
Copy link
Owner

kuba-- commented May 28, 2024

btw. appending data to existing archive is possible with a flag, e.g.:

struct zip_t *zip = zip_open("foo.zip", ZIP_DEFAULT_COMPRESSION_LEVEL, 'a');
{
    zip_entry_open(zip, "foo-3.txt");
    {
        const char *buf = "Append some data here...\0";
        zip_entry_write(zip, buf, strlen(buf));
    }
    zip_entry_close(zip);
}
zip_close(zip);

If we are talking to append to non-zip archive, it can be pretty nice feature. The only concern I have is potential upgrade of miniz. If we can make it as painless as possible for future upgrades, it could be great.

Thanks,

@LemonBoy
Copy link
Contributor Author

LemonBoy commented Jun 1, 2024

Fair enough, I've reworked the patch and submitted it to miniz.

Once/when it's merged I'll update this patch too.

The new miniz version correctly computes the archive starting offset.
@LemonBoy
Copy link
Contributor Author

The latest commit updated miniz and makes some minimal changes to zip itself, there's a bunch of refactoring to avoid the need to introduce the noreopen and rpb functions in miniz.

If you want to perform the miniz update yourself and re-add whatever patches were applied feel free to do so.

LemonBoy and others added 2 commits June 14, 2024 18:37
Use the correct mkdir signature on Windows vs other platforms.
Remove CHMOD macro, it was simply wrapping the chmod libc call.
@kuba--
Copy link
Owner

kuba-- commented Jun 29, 2024

@LemonBoy - PTAL, I submitted some changes to your PR. It's mostly related to fix permission tests. So, I also added back external attributes (what is useful on UNIX).

@LemonBoy
Copy link
Contributor Author

LGTM, I'd advise to submit as many changes as possible to the upstream to simplify further updated down the road.

@kuba-- kuba-- merged commit 8aa5ad2 into kuba--:master Jul 21, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants