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

Consider moving to minizip-ng #19

Open
Neustradamus opened this issue Jan 16, 2019 · 5 comments
Open

Consider moving to minizip-ng #19

Neustradamus opened this issue Jan 16, 2019 · 5 comments

Comments

@Neustradamus
Copy link

@stachenov
Copy link
Owner

A good idea, but unfortunately pretty hard to implement. QuaZIP uses modified minizip. Some modifications were made to introduce very specific features, but the most critical one is that QuaZIP can open ZIP files which are not really files, but some other QIODevices like QBuffer. Therefore, I had to change the IO API of minzip to accept anything as a file name, not just a string. So to update minizip I first have to reapply these changes, and I have to do it every time I update. Or, better yet, issue PRs to the minizip project to make these changes there, but then I obviously have to do it in a compatible way. Maybe I'll get to it when I have time, but not in the foreseeable future.

@jannkoeker
Copy link

You should take a closer look at the new minizip which is now located under https://github.com/zlib-ng/minizip-ng
They support the creation of your own file backend via mz_strm, a reference implementation for posix api and win32 api is provided (mz_strm_os_*.c). You woud only need to implement 10 callback functions.

If you want, i can also give you my implementation.

@stachenov
Copy link
Owner

I've already took a look. It certainly looks promising, but it still lacks some features.

First, that mz_strm.h has this definition

typedef int32_t (*mz_stream_open_cb)           (void *stream, const char *path, int32_t mode);

This, unfortunately, means that it still uses a string as the path. I can't possibly implement this API to open a QBuffer instead, for example. Unless I'm willing to go all UB and just case that path to QBuffer *, but that's silly.

There are also other modifications that were introduced to Minizip in QuaZip, such as the ability to disable descriptor writing for compatibility with really, really old ZIP versions (1.0 even, I think). I'd have to either ditch those features or have them implemented in minizip-ng.

Overall it seems like a very good idea for QuaZip 2.0. Unfortunately, I'm a bit short on time lately, so I've absolutely no idea when I'm able to get to it, if at all. Sad, but true.

@jannkoeker
Copy link

As for the callback, you would implement it yourself so you could just ignore the parameter, which would mean the user would have to manage the QIODevice themselves (e.g. setting the path for QFile).
The ability to disable descriptor writing is part of the library.
mz_zip_set_data_descriptor(void* handle, uint8_t data_descriptor) with data_descriptor = 0 to disable, 1 to enabel.

As for the mz_stream struct, you may use the attached files. If you use them you may use any license you see fit.
mz_strm_qiodevice.zip

Usage is rather simple: either use the create and destroy functions then you need to manually set the QIODevice to use, or you can use the constructor via new and pass a pointer of a QIODevice there. the resulting object may be used in any function that takes a mz_stream instance

@stachenov
Copy link
Owner

OK, that's good news.

But I'll still need some time to figure it all out and make sure I don't break existing API.

The QuaZip test suite being not quite thorough doesn't help either.

@cen1 cen1 changed the title minizip update? Consider moving to minizip-ng Oct 12, 2024
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

No branches or pull requests

3 participants