Address sanitizer shows memory leaks with various errors or failure paths:

• archive_open_named/3 with an entry name that's not in the archive
• open_archive_entry/3 (with or without close/1)
• archive_create/3 with file that doesn't exist
  and probably others (I haven't exercised quite a bit of the API).

Strange error when using archive_open/4 with Mode=write:

?- [library(archive)].
?- open('a.bz2', write, Out), archive_open(Out, write, Arch, [filter(bzip2),format(empty)]).
ERROR: option `format' does not exist in [filter(bzip2),format(empty)]

It's not clear to the programmer what is wrong here: option format does seem to be part of the options list.

The commit of 18/Apr/2022 ("CLEANUP: Removed references to libarchive versions before 3.0.0a") altered the signatures of ar_skip() and ar_seek() to use the typedef la_int64_t instead of the macro __LA_INT64_T but this is not defined in libarchive 3.1.2

I suppose I might s/la_int64_t/int64_t/ to get SWI-Prolog 8.5.11 onwards to build under CentOS 7?

yum update is not offering us any updates to libarchive 3.1.2 release 14.e17_7 :-/

For write, there are additional formats supported, such as shar, warc, rar_v5.
The AC_CHECK_FUNCS in CMakeLists.txt should also have "archive_write_support_format_XXX", and config.h.cmake updated accordingly. Also, archive4pl.c should use these in the write context -- currently, the code assumes that a format is available for writing only if it's available for reading.

archive_data_stream/3 should be able to enumerate all entities, but I consistently receive a permission error for the deterministic case beyond the first entry.

Reproducible case

:- use_module(library(archive)).
:- use_module(library(http/http_open)).

test :-
  setup_call_cleanup(
    http_open('http://geodata.nationaalgeoregister.nl/wijkenbuurten2016/extract/wijkenbuurten2016.zip', In1, []),
    setup_call_cleanup(
      archive_open(In1, Archive, [close_parent(false),filter(all),format(zip)]),
      call_cleanup(
        (
          archive_data_stream(Archive, In2, [meta_data(Metadata)]),
          writeln(Metadata)
        ),
        close(In2)
      ),
      archive_close(Archive)
    ),
    close(In1)
  ).

Output

?- test.
[archive_meta_data{filetype:file,filters:[],format:zip 2.0 (deflation),mtime:1468849076.0,name:Uitvoer_shape/buurt_2016.prj,permissions:436,size:428},archive_meta_data{filetype:file,filters:[],format:raw,mtime:0.0,name:data,permissions:420,size:0}]
true ;
ERROR: No permission to next_header archive `<archive>(0x10b8570)'

Expected

Either the second entry of the archive, if any, or non-deterministic success.

In the current implementation, archive_data_stream/3 can be called for an archive that was previously opened with archive_open/[3,4]. If the parent archive was opened with filter options other than filter(all), then these filter options are no longer available once archive_data_stream/3 opens child archives.

The inability to share filter options between opening the parent archive and opening a child archive leads to practice problems when filter/1 options specify every filter except for mtree (a text-based compression format that is little used, but does regularly result in false positives). Even if the parent is opened without mtree support, the child archives are still opened with filter(all), and thus the false positives persist.

Suggestion: allow archive_data_stream/3 to lookup and reuse the filter/1 options that the parent archive was opened with.

By default libarchive pads the block to 10240 bytes unless you call

archive_write_set_bytes_in_last_block(ar->archive, 1);

after creating the archive. This only happens if you use the callback-style handlers - if you write the file to disk directly then no padding is added.

This isn't technically a bug - the file generated is still legal, however some decompressors (notably, the jar decompressor built into java, at least in java 1.8) fails to read them correctly.

Is there any reason not to change this? If no, I'll create a PR