Tim Kientzle

> If the decompression dictionary is cached when listing the archive contents ... Do you have a proof-of-concept?

The usual concern with this kind of approach is the size of the checkpoint data, which has to be stored either in memory or in this case, in a separate...

This is a big project. Are you up for it? There are a number of pieces to what you're proposing: 1. Adding an opaque "location" to archive_entry so that the...

I'm not thrilled about having multiple build systems, and as @ds-sloth pointed out, CMake is very common and hence well understood by our downstream users. I admit that I've long...

For Zip, if we had an offset to the file data in the `archive_entry` structure, you could seek to that location and then decompress the data yourself. The standard compression...

Another approach that would work for Tar and Zip (but not ISO) would be to store the start-of-_header_ offset in the archive_entry (possibly in addition to the start-of-_data_ offset). You...

> For ZIP with compressed entries, how could one record the start-of-header offset? This would require changes to libarchive. We could modify the code in `archive_read_support_format_zip.c` to record the offset...

Really, if you want random access to content stored in ISO9660 images and Zip archives, I'm sure there are more suitable libraries than libarchive. Libarchive is heavily oriented to handle...

> It looks like there's no way to re-seek to an archive_entry, yet there is a way to extract it to the filesystem by passing the archive_entry to archive_read_extract(). To...

> > Currently, what would entail trying to duplicate/memcpy the struct archive_read? > I would not recommend trying this. There's far too much state spread across far too much code....