LibZip Vs miniZip - Best way to handle .zip Files

[SrisharanVS]

Hi Developers,

As the Title suggests, what is the best way to deal with .zip files. I mean to create, delete, display, and do other possible operations. I want write to write a program that uses either of the libraries or any new library to achieve the said operations.

If there are newer ways to handle .zip files, share it here..

[aral-matrix]

This is just my opinion having had the same question and opted for libzip:

Make your decision based on whether you want your users to have to download minizip from an external source:
The (debian) libminizip-dev package appears not to offer the same API as the minizip repository, and it is not entirely clear to me which fork of minizip (minizip vs. minizip-ng) is the baseline to use.

I chose libzip because it is available as a functioning library on my debian system, and I prefer that over having to clone directly from an upstream repository.

That said, the libzip documentation is ... lacking, to say the least. You'll need examples and some trial & error.

[0-wiz-0]

Could you please expand what you're missing in the documentation?
All the functions are documented https://libzip.org/documentation/ and there are examples for more complicated cases https://github.com/nih-at/libzip/tree/main/examples

[aral-matrix]

Could you please expand what you're missing in the documentation?

I responded to @dillof in own discussion thread to the same question - in addition to my generic answer there, one of the really difficult bits is that the function parameters are not individually explained (what is their type, valid range, how are they obtained), but mentioned in a prose sentence explaining the use of the documented function.

This is kind of hard to understand, especially without a flowchart of function calls needed to get the archive into a state where the documented function can be called.
Take for example https://libzip.org/documentation/zip_file_add.html which states for source

The data is obtained from the source argument, see zip_source(3).

And following that link, there's a huge description paragraph about functions that can be used to obtain a zip_source_t, without giving a new user an overview over what a source is or a decision help why and which of those functions they should use to obtain a source variable in order to add a file to an archive.

[dillof]

Could you please expand what you're missing in the documentation?

I responded to @dillof in own discussion thread to the same question - in addition to my generic answer there, one of the really difficult bits is that the function parameters are not individually explained (what is their type, valid range, how are they obtained), but mentioned in a prose sentence explaining the use of the documented function.

This is kind of hard to understand, especially without a flowchart of function calls needed to get the archive into a state where the documented function can be called. Take for example https://libzip.org/documentation/zip_file_add.html which states for source

The data is obtained from the source argument, see zip_source(3).

And following that link, there's a huge description paragraph about functions that can be used to obtain a zip_source_t, without giving a new user an overview over what a source is or a decision help why and which of those functions they should use to obtain a source variable in order to add a file to an archive.

We've reworked the zip_source_t man page to give more detail about the different types of sources available.

There are no special states structures need to be in, so I don't know what you would like documented there.

We've also split the sections describing the central data structures into their own pages.

[aral-matrix]

We've reworked the zip_source_t man page to give more detail about the different types of sources available.

If memory serves me well, your update amounts to this:

Data can come from a file on disk [..], memory ([..]), a file inside an archive ([..]), or provided via a callback function ([..]).
[..] or [..] can be used restrict access to a part of the contained data.

So yes, that is much better :) This is probably the part I struggled with the most.

There are no special states structures need to be in, so I don't know what you would like documented there.

I was referring to e.g. a zip source having a longer (required) lifetime than a zip_t archive, which depends on the source. From my initial newbie point of view, I would have assumed the opposite.

So something like:

"Before opening a zip archive, the zip source parameter must be initialized (link to relevant man page or functions)."

We've also split the sections describing the central data structures into their own pages.

Oh - are the below ones newly separate? I do not fully recall how it was documented before.

https://libzip.org/documentation/zip.html
https://libzip.org/documentation/zip_file.html
https://libzip.org/documentation/zip_source.html
https://libzip.org/documentation/zip_source.html

Yes, in that case, that's a huge improvement. :)

[0-wiz-0]

There are no special states structures need to be in, so I don't know what you would like documented there.

I was referring to e.g. a zip source having a longer (required) lifetime than a zip_t archive, which depends on the source. From my initial newbie point of view, I would have assumed the opposite.

Yes, that can be confusing. We've mentioned this in a couple more places now.

So something like:

"Before opening a zip archive, the zip source parameter must be initialized (link to relevant man page or functions)."

Sorry, but that is too obvious for us - do not pass invalid parameters :-)

Thanks for the suggestions!

[aral-matrix]

Yes, that can be confusing. We've mentioned this in a couple more places now.

thumbsup

"Before opening a zip archive, the zip source parameter must be initialized (link to relevant man page or functions)."

Sorry, but that is too obvious for us - do not pass invalid parameters :-)

You might be forgetting that some parameters are initialized by reference :). But admitted, this comment of mine was maybe poorly phrased regarding the workflow that initially confused me.

I have just written down a lot of ideas for documentation improvement, and since it became much more text than I had initially planned, I will move this to a new discussion thread so as not to flood this one: #492