Tim Kientzle

Are you building with libz? Or are you falling back to the command-line gzip? Coincidentally, #2724 suggests the gzip command-line program may not fully populate the gzip header in the...

So this may just be a case where we need to skip (or at least relax) those tests when libarchive is not using its built-in gzip support.

Yes, that does suggest that libz is being used. Could you try reverting those two commits you mentioned and see if that changes anything?

I'm not sure this is actually the right fix. I think that `archive_libexpat_version` should only return non-NULL if libarchive is actually _using_ it. In `archive_read_support_format_xar.c`, we use libexpat only if...

You're right that the libarchive API does not currently support asynchronous operation. It would indeed be a pretty big change, since it would likely require major alterations to every single...

I skimmed through the logs you uploaded to Dropbox. Most of those look pretty innocent -- it looks like we should adjust some of those tests to be more tolerant...

If `./configure` can find libz, it should use it in the build. That would enable libarchive's built-in gzip handling (and also get you the core support needed for Zip archives)....

I played with your sample file using bsdtar, and I think that it actually is using the seeking reader for your case. The seeking reader reads _BOTH_ the central directory...

The function that gets the next entry in a Zip archive when reading in seeking mode is here: https://github.com/libarchive/libarchive/blob/d06700a0986b80c456d82800eaf1de872cf9ea6c/libarchive/archive_read_support_format_zip.c#L4269 It checks whether we have the central directory read into memory...

Sorry for the confusion. It's been a long time since I last looked at this code. It looks like `rsrc` is just for connecting macOS metadata entries and so is...