Bug #52091 [Com]: ZipArchive: CRC32 errors / corrupted archives not reported
Edit report at http://bugs.php.net/bug.php?id=52091&edit=1
ID: 52091
Comment by: schmale at froglogic dot com
Reported by:hardcorevenom at gmx dot de
Summary:ZipArchive: CRC32 errors / corrupted archives not
reported
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Linux
PHP Version:5.2.13
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
Not the same bug, but related, as "ZipArchive::extractTo" seems to fail
in giving a meaningful return value at all.
I used the method and specified an existing directory without write
privileges, and got TRUE as return value (although
"ZipArchive::extractTo" didn't do anything, due to lack of write
privileges).
Previous Comments:
[2010-06-23 18:38:26] hardcorevenom at gmx dot de
File "_test.php" is bad in this archive
http://www-user.tu-chemnitz.de/~womar/test/zipview/test_broken.zip
Can be seen here:
http://www-user.tu-chemnitz.de/~womar/test/zipview/ziptest.php?file=test_broken.zip
[2010-06-20 17:57:17] paj...@php.net
Do you have an archive to reproduce this problem (small if possible :)?
[2010-06-16 00:35:49] hardcorevenom at gmx dot de
"Actual result" should be
CRC32 errors are reported not always.
[2010-06-15 23:29:45] hardcorevenom at gmx dot de
Summary modified.
[2010-06-15 23:26:34] hardcorevenom at gmx dot de
Description:
I corrupted a file using a hex editor.
"echo shell_exec('unzip -t file')" shows the CRC32 mismatch.
ZipArchive::extractTo() doesn't report CRC32 errors.
Reading a stream received from ZipArchive::getStream('myfile') echoes a
CRC error if the number of bytes read with one fread() is below 2157
bytes.
Test script:
---
$zip = new ZipArchive();
if ($zip->open('test.zip')) {
zip->extractTo('mydir'); //no error printed
$fp = $z->getStream('brokenfile');
while (!feof($fp)) {
$buf .= fread($fp, 2048+108); //CRC error printed
}
$fclose($fp);
$fp = $z->getStream('brokenfile');
while (!feof($fp)) {
$buf .= fread($fp, 2048+109); //CRC error NOT printed
}
$fclose($fp);
zip.close()
}
Expected result:
A CRC32 error report that can be handled.
The one from "fread($fp, 2048+108)" is fine: "Warning: fread()
[function.fread]: Zip stream error: CRC error in ..." (can be handled
with "ob_get_contents()");
For "ZipArchive::extractTo()" the corrupt file(s) should be printed.
Actual result:
--
CRC32 errors are reported always.
--
Edit this bug report at http://bugs.php.net/bug.php?id=52091&edit=1
[PHP-BUG] Bug #53893 [NEW]: Wrong return value for ZipArchive::extractTo()
From:
Operating system: Linux
PHP version: 5.3.5
Package: Zip Related
Bug Type: Bug
Bug description:Wrong return value for ZipArchive::extractTo()
Description:
PHP version (as given in phpinfo()): PHP Version 5.3.3-1ubuntu9.3
Zip-related information:
Zip enabled
Extension Version $Id: php_zip.c 300470 2010-06-15 18:48:33Z pajoye $
Zip version 1.9.1
Libzip version 0.9.0
Test script:
---
function testReturnValue() {
$extractToPath = "/home/user/testDir"; /* existing dir with NO
write privileges */
$zipPath = "path/to/zipFile"; // has to be valid zip file
$zip = new ZipArchive();
$open = $zip->open($zipPath);
if ($open === true) {
$extracting = $zip->extractTo($extractToPath);
$zip->close();
return $extracting;
} else {
return false;
}
}
Expected result:
Return value of testReturnValue() should be FALSE, as long as the php user
has no write access to the directory into which we extract the zip (because
if that's the case, nothing will happen).
Actual result:
--
Return value is TRUE, even if no extracting happened due to lacking
privileges.
--
Edit bug report at http://bugs.php.net/bug.php?id=53893&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53893&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53893&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53893&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53893&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53893&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53893&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53893&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53893&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53893&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53893&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53893&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53893&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53893&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53893&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53893&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53893&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53893&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53893&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53893&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53893&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53893&r=mysqlcfg
Bug #53893 [Fbk->Opn]: Wrong return value for ZipArchive::extractTo()
Edit report at http://bugs.php.net/bug.php?id=53893&edit=1
ID: 53893
User updated by:schmale at froglogic dot com
Reported by:schmale at froglogic dot com
Summary:Wrong return value for ZipArchive::extractTo()
-Status: Feedback
+Status: Open
Type: Bug
Package:Zip Related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
No, it's just an arbitrary zip file. Not empty, of course. In my case,
it was a zip file of approx. 50kb size.
If I deleted the existing directory, the zip file was extracted
perfectly. However, extracting the zip file into a directory with no
write privileges did nothing at all. This is desired behaviour, of
course, if it wasn't for the return value: The ZipArchive::extractTo's
return value was TRUE either way, which lead to some confusion.
Previous Comments:
[2011-01-31 21:36:11] fel...@php.net
Hello, I've a doubt about the test case. $zipPath points to an empty zip
file?
----
[2011-01-31 17:49:03] schmale at froglogic dot com
Description:
PHP version (as given in phpinfo()): PHP Version 5.3.3-1ubuntu9.3
Zip-related information:
Zip enabled
Extension Version $Id: php_zip.c 300470 2010-06-15 18:48:33Z pajoye $
Zip version 1.9.1
Libzip version 0.9.0
Test script:
---
function testReturnValue() {
$extractToPath = "/home/user/testDir"; /* existing dir with NO
write privileges */
$zipPath = "path/to/zipFile"; // has to be valid zip file
$zip = new ZipArchive();
$open = $zip->open($zipPath);
if ($open === true) {
$extracting = $zip->extractTo($extractToPath);
$zip->close();
return $extracting;
} else {
return false;
}
}
Expected result:
Return value of testReturnValue() should be FALSE, as long as the php
user has no write access to the directory into which we extract the zip
(because if that's the case, nothing will happen).
Actual result:
--
Return value is TRUE, even if no extracting happened due to lacking
privileges.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53893&edit=1
[PHP-BUG] Bug #54028 [NEW]: Directory::read() cannot handle non-unicode chars properly
From:
Operating system: Windows 7
PHP version: 5.3.5
Package: Directory function related
Bug Type: Bug
Bug description:Directory::read() cannot handle non-unicode chars properly
Description:
Notice: This problem does ONLY affect the CLI interpreter, NOT the CGI.
Using dir('path/to/dir'), the read() method does not return UTF-8, if the
directory contains e.g. umlauts (ä, ö, ü). I tested this on Linux and
Windows, both CGI and CLI, and the problem does only occur with
Windows/CLI.
Test script:
---
$path = 'path/to/directory/which/contains/umlauts';
$directory = dir($path);
while (false !== ($content = $directory->read())) {
if (mb_check_encoding($content, 'UTF-8') === false) {
fprintf(STDERR, 'Returned non-utf-8 (%s)', $content);
}
}
Expected result:
The expected result, of course, was that the return value of read is always
encoded in UTF-8, i.e. no messages are print, when we run the script.
Actual result:
--
If a subdirectory contains umlauts (or I guess any non-unicode character),
a message is print, i.e. the return value is not encoded in UTF-8.
--
Edit bug report at http://bugs.php.net/bug.php?id=54028&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54028&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54028&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54028&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54028&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54028&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54028&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54028&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54028&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54028&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54028&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54028&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54028&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54028&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54028&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54028&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54028&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54028&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54028&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54028&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54028&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54028&r=mysqlcfg
Bug #54028 [Bgs]: Directory::read() cannot handle non-unicode chars properly
Edit report at http://bugs.php.net/bug.php?id=54028&edit=1
ID: 54028
User updated by:schmale at froglogic dot com
Reported by:schmale at froglogic dot com
Summary:Directory::read() cannot handle non-unicode chars
properly
Status: Bogus
Type: Bug
Package:Directory function related
Operating System: Windows 7
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Well, I don't know what Windows uses as encoding, but I sure do know,
that it works properly with the Windows CGI version. The point is, a
directory called 'Startmenü' will return 'Startmenü' with Linux/CGI,
Linux/CLI, Windows/CGI, but NOT with Windows/CLI - the latter returning
'Startmenñæ' (or sth similar). In other words: The behaviour with
Windows/CLI is broken, where the other versions return the exact name of
the directory, as expected.
So I think it has nothing (little) to do with unicode filesystem support
or the encoding of Windows, but with differences between CGI and CLI.
Previous Comments:
[2011-02-15 16:54:17] paj...@php.net
There is already a feature request for unicode filesystem support.
Btw, Windows does not use UTF-8 for its encoding.
--------
[2011-02-15 16:51:20] schmale at froglogic dot com
Description:
Notice: This problem does ONLY affect the CLI interpreter, NOT the CGI.
Using dir('path/to/dir'), the read() method does not return UTF-8, if
the directory contains e.g. umlauts (ä, ö, ü). I tested this on Linux
and Windows, both CGI and CLI, and the problem does only occur with
Windows/CLI.
Test script:
---
$path = 'path/to/directory/which/contains/umlauts';
$directory = dir($path);
while (false !== ($content = $directory->read())) {
if (mb_check_encoding($content, 'UTF-8') === false) {
fprintf(STDERR, 'Returned non-utf-8 (%s)', $content);
}
}
Expected result:
The expected result, of course, was that the return value of read is
always encoded in UTF-8, i.e. no messages are print, when we run the
script.
Actual result:
--
If a subdirectory contains umlauts (or I guess any non-unicode
character), a message is print, i.e. the return value is not encoded in
UTF-8.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54028&edit=1
