|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2006-09-15 08:50 UTC] d dot o dot m dot e at gmx dot net
Description:
------------
I want to add files to a newly created and not yet existing zip-archive by using the method 'ZipArchive::addFile'.
Reproduce code:
---------------
<?php
$zip = new ZipArchive();
$filename = 'zipfile.zip';
$testfile = $_SERVER['DOCUMENT_ROOT'] . '/foo.jpg';
$testfile2 = 'foo2.jpg';
if($zip->open($filename, ZIPARCHIVE::CREATE)===TRUE)
{
$zip->addFromString('testfile.txt', 'This is a test string added.');
if(file_exists($testfile)) $zip->addFile($testfile, 'foo.jpg');
if(file_exists($testfile2)) $zip->addFile($testfile2, 'foo2.jpg');
if(file_exists($testfile2)) $zip->addFile($testfile2, 'folder/foo2.jpg');
$zip->close();
}
else die('Can\'t create Zip-archive.');
?>
Expected result:
----------------
I expected newly created zip-archive with the following document tree:
root
|-foo.jpg
|-foo2.jpg
|-testfile.txt
|-folder
|-foo2.jpg
Actual result:
--------------
The actual result is the expected document tree, but the compressed files can't be opened by using the Windows decompression wizard. The error message of the wizard states 'Unexpected end of file'.
The only exception is the 'testfile.txt' which CAN be extracted and opened (which is beacause it uses a different method).
The method 'addFile' returns TRUE with all files.
Furthermore, it IS possible to browse through the zip-archive.
Even the file size and the compressed file size of the files are correct compared to a manually created zip archive, but the total size of the archive is bigger.
I also doublechecked the files 'foo.jpg' and 'foo2.jpg' that they are at the right position and not damaged.
Note: Probably is has something to do with the fact that the second parameter doesn't seem to be optional like it is said in the documentation. Leaving it out doesn't even add the file to the zip-archive.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Wed Oct 22 08:00:01 2025 UTC |
Dominikus, your test file has CRLF (0x0d, 0x0a) where it should contain LF (0x0a) only. This *could* have been caused by downloading the file in ASCII mode via FTP, for example. An attempt to repair the file by replacing CRLF with LF resulted in a too short file (according to the unzip program). So, indeed, this looks like a bug in the zip extension. Just to make sure, please apply the following patch to your script: --- zip.txt 2006-09-15 14:50:00.000000000 +0200 +++ zip.txt.new 2006-09-21 11:00:08.000000000 +0200 @@ -14,6 +14,8 @@ if(file_exists($testfile2)) $zip->addFile($testfile2, 'foo2.jpg'); if(file_exists($testfile2)) $zip->addFile($testfile2, 'folder/foo2.jpg'); $zip->close(); + + echo sha1_file($filename) . " $filename\n"; } else die('Can\'t create Zip-archive.'); Then, remove your zip file on the server, and run the script to create it again. The SHA1 sum for the file on the server should be displayed. Download the file, and compare the SHA1 sums; they should be equal. See <URL:http://lists.gnupg.org/pipermail/gnupg-announce/2004q4/000184.html> for where to get sha1sum.exe for Windows systems. For the record, I tested this using the CVS sources from the PHP_5_2 branch, dated 2006-09-15T14:30:00+0200, module php5, compiled on Linux with configure --disable-all --enable-zip --disable-cgi --enable-cli --with-zend-vm=GOTO. Looking into it a bit deeper shows that ext/zip/lib/zip_open_file.c with signature $NiH: zip_source_file.c,v 1.2 2004/11/18 16:28:13 wiz Exp $ , line 60, *has* "b" in the mode flags for fopen(3). (I was told that *not* doing so could cause problems on Windows systems.) So I'm unsure where this bug originates. Please run the test described above and report the result. Thanks.