Problem

Two error paths in lib/zip_source_file_stdio_named.c drop information or resources:

_zip_fopen_close_on_exec opens the file and then wraps the descriptor with fdopen. When fdopen fails, for example under memory pressure, the function returns NULL without closing the descriptor. The descriptor is never released again: the caller only sees the failure. zip_fdopen handles the same situation by closing the descriptor before returning, so the helper is missing the matching cleanup. Since the helper is used every time a named archive is opened for reading and when the clonefile path opens the temporary file, an application that retries opening archives under memory pressure accumulates descriptors.

In _zip_stdio_op_create_temp_output_cloning, when ftruncate fails while sizing the freshly created clone target, the function cleans up the temporary file but returns without setting an error code. Every other failure in the function reports ZIP_ER_TMPOPEN with the errno value. A caller of zip_source_begin_write_cloning that hits a real truncate failure, for instance because the filesystem rejects the file size, gets a failed call whose error state still reads as no error.

Change

The descriptor is closed when fdopen fails, and the ftruncate failure path sets ZIP_ER_TMPOPEN with errno, matching the rest of the function.

Testing

Since neither failure can be triggered portably through the public API alone, I verified both with fault injection on Linux in a scratch workflow that builds current main and this change side by side and interposes fdopen and ftruncate via LD_PRELOAD:

• Opening an archive four times with a failing fdopen: on main the process holds 9 open descriptors where it held 5 before, one leaked per attempt; with this change the count stays at 5.
• Calling zip_source_begin_write_cloning with a failing ftruncate: on main the call fails but reports No error; with this change it reports Failure to create temporary file: Input/output error.

Successful paths are unchanged: the full regress suite passes, 193 tests, and the upstream workflows are green on Linux, macOS, Windows, BSD and Solaris.