stachenov / quazip

Qt/C++ wrapper over minizip
Other
554 stars 231 forks source link

minizip update? #19

Open Neustradamus opened 5 years ago

Neustradamus commented 5 years ago
stachenov commented 5 years ago

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 commented 3 years ago

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_strmos*.c). You woud only need to implement 10 callback functions.

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

stachenov commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.