ID:               43641
 Updated by:       [EMAIL PROTECTED]
 Reported By:      max630 at gmail dot com
 Status:           Analyzed
 Bug Type:         Zip Related
 Operating System: linux/amd64
 PHP Version:      5.2.5
 Assigned To:      pajoye
 New Comment:

It is as the offset_t supports a larger range. The whole offset system
uses a larger range.


Previous Comments:
------------------------------------------------------------------------

[2007-12-20 13:24:41] max630 at gmail dot com

Files in question are not huge at all - the dir900.zip is just about
100K. So, strictly speaking, it is not a huge file support.

------------------------------------------------------------------------

[2007-12-20 12:50:08] [EMAIL PROTECTED]

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 10:43:28] max630 at gmail dot com

Description:
------------
ZipArchive fails on opening some zip archives

file which php fails on is here:
http://max630.info/dir900.zip

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
http://ftp.de.debian.org/debian/pool/main/libz/libzip/libzip_0.8-1.dsc
- which is where the builtin implementation came from - opens all files
I have tested without errors

Reproduce code:
---------------
<?php

$z = new ZipArchive;

$status = $z->open("dir900.zip");

if ($status !== TRUE) {
    print_r($status);
    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/dir900.zip", 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


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=43641&edit=1

Reply via email to