4.1.0 build failing tests on gcc 14 + cmake 4.2.2 with Error -111

[akrherz]

Greetings, I attempt to keep the conda-forge build of minizip-ng current. Building 4.1.0 is experiencing a number of test failures, for example:

  7/211 Test   #7: raw-erase-unzip-generic ..........***Failed    0.00 sec
minizip-ng 4.1.0 - https://github.com/zlib-ng/minizip-ng
---------------------------------------------------
-x -o -d $SRC_DIR/build/Testing/Temporary/raw-generic $SRC_DIR/build/Testing/Temporary/raw-generic.zip 
Archive $SRC_DIR/build/Testing/Temporary/raw-generic.zip
Error -111 opening archive $SRC_DIR/build/Testing/Temporary/raw-generic.zip

My blissfully ignorant assumption is that warning may be to blame?

CMake Warning (dev) at /home/conda/feedstock_root/build_artifacts/minizip_1769305791926/_build_env/share/cmake-4.2/Modules/FetchContent.cmake:1963 (message):
  Calling FetchContent_Populate(googletest) is deprecated, call
  FetchContent_MakeAvailable(googletest) instead.  Policy CMP0169 can be set
  to OLD to allow FetchContent_Populate(googletest) to be called directly for
  now, but the ability to call it with declared details will be removed
  completely in a future version.
Call Stack (most recent call first):
  test/CMakeLists.txt:40 (FetchContent_Populate)
This warning is for project developers.  Use -Wno-dev to suppress it.

Here's the compile log

log.txt

[pmqs]

@akrherz does PR #946 fix the issue for you? If so, can you close the issue please?

[akrherz]

Thank you @pmqs ! While the cmake warning went away, the test failures persisted

log2.txt

[pmqs]

Thank you @pmqs ! While the cmake warning went away, the test failures persisted

Good

log2.txt

I had that error intermittently. A reboot made it go away. No idea what the root-cause was.

[pmqs]

... While the cmake warning went away, the test failures persisted

Just figured out why I was getting the same test failures as you.

The root directory for my dev environment is a symbolic link. That then impacts a number of testes where the code is extracting the contents of a zip file. As the code stands it will not allow extraction of there is a symlink in the target path. That seems wrong, but need to understand what the code is doing.

Is there a symlink in any of the paths where you are running the tests?

[akrherz]

Is there a symlink in any of the paths where you are running the tests?

I am unsure and am getting a different test failure in the case of symlinks than what the logs above show

Extracting foo
Error -107 saving entries to disk fuzz/unzip_fuzzer_seed_corpus/encrypted_wzaes.zip

[pmqs]

Is there a symlink in any of the paths where you are running the tests?

I am unsure and am getting a different test failure in the case of symlinks than what the logs above show

Extracting foo
Error -107 saving entries to disk fuzz/unzip_fuzzer_seed_corpus/encrypted_wzaes.zip

I also see that test failing when I have a symlink in the dev directory tree

I you get a chance, can you try running the tests in a directory tree without any symlinks to see if you get any test failures?

This is what I used to stick the build artefacts into /tmp/build. All test passed.

$ cmake -S . -B /tmp/build -D MZ_CODE_COVERAGE=ON -D MZ_BUILD_TESTS=ON     -D MZ_BUILD_UNIT_TESTS=ON     -D BUILD_SHARED_LIBS=OFF     -D CMAKE_BUILD_TYPE=Debug
$ cmake --build /tmp/build
$ (cd /tmp/build; ctest   --output-on-failure     -C Debug  )

[akrherz]

can you try running the tests in a directory tree without any symlinks to see if you get any test failures?

I do not get test failures locally on a current Alma Linux 9 x86_64 build, but the conda-forge environment continues to error on the various platforms. I keep boggling how to reproduce that :/

[pmqs]

can you try running the tests in a directory tree without any symlinks to see if you get any test failures?

I do not get test failures locally on a current Alma Linux 9 x86_64 build, but the conda-forge environment continues to error on the various platforms. I keep boggling how to reproduce that :/

Sorry, don't know anything about conda-forge

If it isn't possible to hack the conda-forge environment you could try backing out the recent changes for symlink processing to see if that helps.

or just wait for a fix to the code.

[pmqs]

Here is a way to reproduce the test failure

$ unzip -l /tmp/fred.zip 
Archive:  /tmp/fred.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     6926  2026-02-02 16:11   mz.h
---------                     -------
     6926                     1 file

$ mkdir /tmp/output

$ ln -s /tmp/output /tmp/linked

$  minizip -x -o -d /tmp/linked /tmp/fred.zip 
minizip-ng 4.1.0 - https://github.com/zlib-ng/minizip-ng
---------------------------------------------------
-x -d /tmp/linked /tmp/fred.zip 
Archive /tmp/fred.zip
Extracting mz.h
Error -107 saving entries to disk /tmp/fred.zip

This is me unzipping into a pre-existing directory tree that happens to include a symbolic link. That shouldn't trigger an error.

It is only an error when the symlink /tmp/linked itself is included in the zip file.

To police that, the code would need to remember the symlinks it has extracted and then check for subsequent writes into that tree. Symlinks with absolute paths feel like they should be straightforward to deal with. If the symlink is a relative path, it make things more complicated. Assume they need to be converted to absolute paths first.

[akrherz]

I certainly appreciate the help and wish that I was more helpful, but just to emphasize that the error I am getting is -111 and not -107

[pmqs]

I certainly appreciate the help and wish that I was more helpful, but just to emphasize that the error I am getting is -111 and not -107

I got both the -107 and -111 errors as well. They seem to be two symptoms of the same underlying issue.