|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #43641 ZipArchive::open() fails to open some archives
Submitted: 2007-12-20 10:43 UTC Modified: 2009-03-04 10:31 UTC
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:1 (33.3%)
From: max630 at gmail dot com Assigned: pajoye (profile)
Status: Closed Package: Zip Related
PHP Version: 5.2.5 OS: linux/amd64
Private report: No CVE-ID: None
 [2007-12-20 10:43 UTC] max630 at gmail dot com
ZipArchive fails on opening some zip archives

file which php fails on is here:

it is just 900 empty files in one directory. Produced by zip utility from a recent Linux distribution (Debian).

This IS NOT an OS issue, as no failed syscall appears in strace. Most probable reason is that in-source zip library is not completely ready for 64-bit wide offsets, but I'm not sure. I'm not even sure that it is the reason of the failure is size of the archive.

I can not reopen Bug #40873 - I am not the original reporter - so here is a new bug

BTW, libzip from
- which is where the builtin implementation came from - opens all files I have tested without errors

Reproduce code:

$z = new ZipArchive;

$status = $z->open("");

if ($status !== TRUE) {
    die("open failed");


Expected result:
$./sapi/cli/php test-zip.php

Actual result:
$./sapi/cli/php test-zip.php
5open failed

noteable piece from strace:
open("/home/max/", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaff7b39000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 122880, SEEK_SET)              = 122880
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"..., 1246) = 1246
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 57344, SEEK_SET)               = 57344
read(3, "K\3\4\n\0\0\0\0\0\374x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16"..., 4096) = 4096
read(3, "\n\0\0\0\0\0\373x\2247\0\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0"..., 61440) = 61440
read(3, "\0\0\0\0\0\0\0\0\0\0\0\16\0\r\0\0\0\0\0\0\0\0\0\244\201"..., 4096) = 1246
brk(0xdce000)                           = 0xdce000
fstat(3, {st_mode=S_IFREG|0644, st_size=124126, ...}) = 0
lseek(3, 4295024640, SEEK_SET)          = 4295024640
read(3, "", 4096)                       = 0
lseek(3, 1104, SEEK_CUR)                = 4295025744
read(3, "", 4096)                       = 0

Note the huge offset. I fixed this specific place ("ext/zip/lib/zip_open.c" line 316), but it still fails on some other zip files. I could not reproduce that failure with test zip yet


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-12-20 12:50 UTC]
I'm working to fix the 64bit huge file support in libzip.

They added it recently but in a relatively bad way and works only on some systems. What I'm doing is to add custom streams support. This way I can use the native IO functions on each platform (especially important on windows) or use the PHP stream functions (as soon as the large file support works or is available).

It is not a small task, so don't hold your breath :)
 [2007-12-20 13:24 UTC] max630 at gmail dot com
Files in question are not huge at all - the is just about 100K. So, strictly speaking, it is not a huge file support.
 [2007-12-20 13:27 UTC]
It is as the offset_t supports a larger range. The whole offset system uses a larger range.
 [2007-12-20 13:29 UTC]
To make it slighty clearer, 0.8.1 (and cvs versions) has large support but in a complete unportable way. There is already unportable issues in the libzip code (patches have been sent) about binary streams and tempfiles. For some reasons, they did not have been applied upstream.

I have sent some mails recently but did not get yet an answer. I also tried to motivate them to use an issue tracker to ease the developments.
 [2007-12-22 17:09 UTC]
Pierre: I have also sent you several mail without any answer..
 [2007-12-22 17:15 UTC]
ah? please drop one in pierre dot dev at gmail dot com
 [2008-06-25 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-03-04 10:31 UTC]
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Apr 14 12:01:28 2024 UTC