This is not related to the issue but I noticed it while trying to debug
it.
Back when this line was introduced in 9c140a681e, the ZipArchive had
not yet exposed this flag as a constant. It was added later with PHP
7.0.8 and we can switch to using it now.
The original implementation was based on ZipArchive::getStream() which
turns out to be very slow and if the archive contains many files, the
unzipping performance is very slow.
The patch changes the implementation to use ZipArchive::extractTo()
unless the extracted entry path contains a folder name ending with dot
(such as some/path./to/file.txt). There is a known upstream bug in the
PHP ZIP extension #77214 (also #74619 and #69477) so that we fall back
to keep using the stream in those cases.
In some cases we may inspect an empty zip file. If we do open
an empty zip file, check that it changed before we attempt to write
it to disk. It may be the case that we were reading the file from
a location that we don't have write access to.
With PHP bug #70322 fixed, ZipArchive::close() did start returning false
and throwing PHP Warnings with recent PHP versions (5.6.14 and up).
Previously (5.6.13 verified) it was returning true, and false in older
versions (5.4.x verified).
This change does silent the 2 "hacky" calls to close() that we perform
in core leaving the 3rd one (used for files having files) unmodified.
A new unit test has been created to cover the close() behavior, ideally
supporting both old and new PHP versions without harcoding any PHP
version.
Note that we don't use to rely much on results coming from close(), and
that's a good thing given the buggy behavior commented above. This just
keeps empty zips working like they were before.
Changes:
* zip_packer can create empty zip archives
* new option to ignore problematic files when creating archive
* detection of non-existent files
* debugging messages for opening of faulty zip archives
* coding style improvements
* no PHP 5.2 hacks
* more unit tests
