Compiled zip support in PHP 5.2.4 64bit can't open archives with large number of files.

[ScHRiLL]

Binary package hint: php5

There is a problem with the compiled zip support in PHP5 package ver. 5.2.4 that comes with Ubuntu 8.04 LTS 64 bit. When php opens archives with large number of files it throws an error. This is a confirmed php5 bug and it effects all 64bit operating system that have php5 ver. 5.2.4 and because this is an LTS version it should be patched.
- To check if this affecting you try this script
Reproduce code:
---------------
#!/bin/sh
rm -rf test1 test2 test1.zip test2.zip
mkdir test1 test2
cd test1
php -r 'for ($i = 1; $i < 800; $i++) system("touch test$i.txt");'
cd ../
zip -r test1.zip test1 > /dev/null
php -r '$zip = new ZipArchive(); var_dump($zip->open("test1.zip"));
var_dump($zip->numFiles);'

cd test2
php -r 'for ($i = 1; $i < 876; $i++) system("touch test$i.txt");'
cd ../
zip -r test2.zip test2 > /dev/null
php -r '$zip = new ZipArchive(); var_dump($zip->open("test2.zip"));
var_dump($zip->numFiles);'

Expected result:
----------------
[mas@sw-nbk01 zip]$ sh ./zip.sh
bool(true)
int(800)
bool(true)
int(876)

Actual result:
--------------
[mas@www zip]$ sh ./zip.sh
bool(true)
int(800)
int(5)
int(0)

Reference: http://bugs.php.net/bug.php?id=40873

-If you would like there is a patch but you'll have to recompile the php from source. Patch is 100% working

--- php-5.2.5/ext/zip/lib/zip_open.c.seek_error 2008-02-05
22:05:03.000000000 +0200

+++ php-5.2.5/ext/zip/lib/zip_open.c 2008-02-05 23:17:05.000000000
+0200

@@ -313,7 +313,7 @@

        /* go to start of cdir and read it entry by entry */

        bufp = NULL;

        clearerr(fp);

- fseek(fp, -(cd->size+cd->comment_len+EOCDLEN), SEEK_END);

+ fseek(fp, -((long)(cd->size+cd->comment_len+EOCDLEN)),
SEEK_END);

        if (ferror(fp) || ((unsigned int)ftell(fp) != cd->offset)) {

            /* seek error or offset of cdir wrong */

            if (ferror(fp))

Reference: http://bugs.php.net/bug.php?id=44055

[Chuck Short (zulcss)]

I just tried this in karmic and I got the expected results. Ill have a look at backporting this fix.

[Joachim Durchholz (jo-durchholz)]

For what's it worth, here's an indirect confirmation for this bug for Hardy.

I'm using SysCP and had problems with APS files (which would be reported as "this is not an APS file").

http://wiki.syscp.org/docs/aps-handbook says under "PHP configuration issues" has this to say:
"Users of a 64bit system with PHP 5.2 must enable the PHP exec function in their configuration for the SysCP vHost. That's because in the 64bit version of PHP 5.2 exists a bug, which makes it impossible to open Zip files including more than 509 files. For that reason a fallback has been implemented which relies on the exec function of PHP. The files will be extracted in the temporary directory using unzip. So exec mustn't be in disabled_functions if you use a 64bit system!"

Applying the described fixes indeed made all the "this is not an APS file" messages go away.
This is fully consistent with the existence of the bug in Hardy. (Seeing the zip_open bug was first reported for PHP 5.1.something, this is less than surprising IMHO.)

I'd like to see this make its way within the next week because a long-scheduled hardware upgrade to a 64-bit machine will be effective then, and we may be unable to apply security fixes for PHP software if they are distributed as zip archives with more than 509 files in the root directory, and no workaround.
Not a large chance of happening, particularly since we're going to upgrade to Karmic ASAP, but if it does happen, we're screwed...

[Chuck Short (zulcss)]

On further review I dont think this would be a good candidate for an SRU.