#46975 [Asn->Fbk]: checking for mysql_config... not found
ID: 46975 Updated by: j...@php.net Reported By: support at silverservers dot com -Status: Assigned +Status: Feedback Bug Type: PHP options/info functions Operating System: CentOS 5.2 PHP Version: 5.2.8 Assigned To: mysql New Comment: Doesn't this work: --with-pdo-mysql=shared,/usr/local/mysql Previous Comments: [2008-12-30 19:10:39] support at silverservers dot com Description: Configure PHP with pdo_mysql fails using --pdo_mysql=shared "checking for mysql_config... not found" mysql_config exists and is "found" for other needs via --with-mysql=/usr/local/mysql configure for pdo does not seem to follow this path. TEMPORARY FIX is to symlink: ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config RESOLUTION: Best would be for pdo_mysql option to follow the path specified in --with-mysql ENVIRONMENT: CentOS 5.2 - source-compiled MySQL5.0.51/Apache1.3.41/PHP5.2.8 -- Edit this bug report at http://bugs.php.net/?id=46975&edit=1
#46966 [Opn->Fbk]: compact() fails for underscored and case-sensitive var names
ID: 46966 Updated by: j...@php.net Reported By: sohaib dot muneer at gmail dot com -Status: Open +Status: Feedback Bug Type: *General Issues -Operating System: Vista +Operating System: * PHP Version: 5.2.8 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2008-12-29 22:32:31] sohaib dot muneer at gmail dot com Description: I have noticed that the function "compact()" fails for underscored variable names OR variable names that have one or more capital letters. For example, compacting $my_name won't work, similarly $myName or $MyName won't work, but $myname would work good. This should be included in the documentation && any reason as to why it's like that ? And yes! i checked the other bug reports, sure I understand the superglobals problem but this is different, underscore and / or case-sensitive variable names don't work -- Edit this bug report at http://bugs.php.net/?id=46966&edit=1
#46347 [Opn->Asn]: parse_ini_file() does not like asterisk (*) in key
ID: 46347 Updated by: j...@php.net Reported By: duke at masendav dot com -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3CVS-2008-11-11 Assigned To: scottmac New Comment: I don't know how to allow literal * in re2c. (\* did not work) And I don't have spare time to debug this. Ask Pierre if he has. Previous Comments: [2008-12-24 13:58:39] scott...@php.net Jani, this wasn't broken by any of the re2c stuff. The changes you made to zend_ini_scanner.l revision 1.48 are the cause. [2008-10-20 21:01:03] duke at masendav dot com More like undocumented feature then. Nothing at http://www.php.net/parse_ini_file says that * cannot be used inside keys. So we are using it in a few in-house applications and this came as unpleasant surprise. We can of course implement a different solution, if you really consider the current (5.2) behaviour bug. In which case it would be nice to have a better explanation in parse_ini_file documentation with regard to what is considered a valid syntax and what not. [2008-10-20 20:45:16] j...@php.net Why should it like it? That looks like a bug that got fixed by the new parser. [2008-10-20 19:40:21] duke at masendav dot com Description: parse_ini_file no longer likes * (asterisk) in configuration keys. Works just fine in PHP 5.2.5 Reproduce code: --- Ini file with the following content: [section] part1.*.part2 = 1 PHP file: http://bugs.php.net/?id=46347&edit=1
#46985 [Com]: ZIP can not produce valid archive
ID: 46985
Comment by: php at undoso dot eu
Reported By: killerbg at gmail dot com
Status: Feedback
Bug Type: Zip Related
Operating System: Windows XP Professional SP3
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
I have the same issue. It seems that compressing short strings works
fine but using huge ones gets them corrupted. Even if the resulting zip
might open, using a simple md5 on both files often prove that they
differs which is not great...
I downloaded PHP 5.2.6 and replaced the php_zip.dll of 5.2.8 by the
5.2.6 version. It fixed the problem right away. There is really some
kind of regression in 5.2.8.
Previous Comments:
[2009-01-01 00:38:55] paj...@php.net
It works just fine here (in apache2 sapi, iis, fcgi and cli).
Can you try the following script please? I suspect some other errors
happening and they are not displayed. Be sure to have display_errors
activated.
By the way, in the latest releases there are "addFromPattern"/"Glob"
functions which let you add recursively something like "*.jpeg" :)
addEmptyDir($local . $file . "/");
archive($path . $file . "/", $local .
$file . "/");
} elseif (is_file($path . $file)) {
if ($count > 128) {
$zip->close();
$zip->open($GLOBALS["file"]);
$count = 0;
}
$zip->addFile($path . $file, $local .
$file);
$count++;
}
}
}
closedir($handle);
}
echo "count: $count\n";
}
$file = 't.zip';
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::CREATE)) === TRUE) {
archive($path, null);
$zip->close();
}
echo "done\n";
[2008-12-31 23:12:49] killerbg at gmail dot com
Here is an archive containing both the corrupted file created with the
new versions, a good file created with the same script and older version
(5.2.6) and the script used -
http://rapidshare.com/files/178582253/Error.zip.html
[2008-12-31 21:21:33] paj...@php.net
I can't reproduce it here (xp sp3 and vista/2k8).
Please provide the file(s) (the minimum required to create a corrupted
archive) and the script you are using.
[2008-12-31 20:27:12] killerbg at gmail dot com
Description:
On Windows XP Professional Service Pack 3 with Apache 2.2.11 and PHP
5.2.8 - PHP 5.2.9 loaded as dynamic module when creating archive and
adding files and/or folders the ouput is incorrect and the file gets
corrupted. Even trying to open it again with the script results error
code 19.
Reproduce code:
---
$file = tempnam("/tmp/", "php");
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::OVERWRITE)) === TRUE)
{
$zip->addEmptyDir("Directory");
$zip->addFile("File");
$zip->close();
}
Expected result:
Correctly created zip archive file with unique name located in the
temporaly directory.
Actual result:
--
Only the firsts few added files visible but corrupted acording to the
crc32 record.
--
Edit this bug report at http://bugs.php.net/?id=46985&edit=1
#46985 [Com]: ZIP can not produce valid archive
ID: 46985
Comment by: killerbg at gmail dot com
Reported By: killerbg at gmail dot com
Status: Feedback
Bug Type: Zip Related
Operating System: Windows XP Professional SP3
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
pajoye(at)php(dot)net, here is the output from your script
http://rapidshare.com/files/178740823/ouput.zip.html
(identical with the two versions)
The file working state is the same as with my script
The php(at)undoso(dot)eu's solution is working here too
when combining php5ts.dll version 5.2.9 (CVS)
with php_zip.dll version 5.2.7 (CVS)
Previous Comments:
[2009-01-01 14:44:00] php at undoso dot eu
I have the same issue. It seems that compressing short strings works
fine but using huge ones gets them corrupted. Even if the resulting zip
might open, using a simple md5 on both files often prove that they
differs which is not great...
I downloaded PHP 5.2.6 and replaced the php_zip.dll of 5.2.8 by the
5.2.6 version. It fixed the problem right away. There is really some
kind of regression in 5.2.8.
[2009-01-01 00:38:55] paj...@php.net
It works just fine here (in apache2 sapi, iis, fcgi and cli).
Can you try the following script please? I suspect some other errors
happening and they are not displayed. Be sure to have display_errors
activated.
By the way, in the latest releases there are "addFromPattern"/"Glob"
functions which let you add recursively something like "*.jpeg" :)
addEmptyDir($local . $file . "/");
archive($path . $file . "/", $local .
$file . "/");
} elseif (is_file($path . $file)) {
if ($count > 128) {
$zip->close();
$zip->open($GLOBALS["file"]);
$count = 0;
}
$zip->addFile($path . $file, $local .
$file);
$count++;
}
}
}
closedir($handle);
}
echo "count: $count\n";
}
$file = 't.zip';
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::CREATE)) === TRUE) {
archive($path, null);
$zip->close();
}
echo "done\n";
[2008-12-31 23:12:49] killerbg at gmail dot com
Here is an archive containing both the corrupted file created with the
new versions, a good file created with the same script and older version
(5.2.6) and the script used -
http://rapidshare.com/files/178582253/Error.zip.html
[2008-12-31 21:21:33] paj...@php.net
I can't reproduce it here (xp sp3 and vista/2k8).
Please provide the file(s) (the minimum required to create a corrupted
archive) and the script you are using.
[2008-12-31 20:27:12] killerbg at gmail dot com
Description:
On Windows XP Professional Service Pack 3 with Apache 2.2.11 and PHP
5.2.8 - PHP 5.2.9 loaded as dynamic module when creating archive and
adding files and/or folders the ouput is incorrect and the file gets
corrupted. Even trying to open it again with the script results error
code 19.
Reproduce code:
---
$file = tempnam("/tmp/", "php");
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::OVERWRITE)) === TRUE)
{
$zip->addEmptyDir("Directory");
$zip->addFile("File");
$zip->close();
}
Expected result:
Correctly created zip archive file with unique name located in the
temporaly directory.
Actual result:
--
Only the firsts few added files visible but corrupted acording to the
crc32 record.
--
Edit this bug report at http://bugs.php.net/?id=46985&edit=1
#46987 [NEW]: Maximum String Length for XML Nodes is not documented
From: eric at midkotasolutions dot com Operating system: RedHat E5 PHP version: 5.2.8 PHP Bug Type: DOM XML related Bug description: Maximum String Length for XML Nodes is not documented Description: Note that there is a limitation to the maximum size of a string for a node. I am submitting here in as documentation. I have a string that is 455K in Size. I tried creating an XML Node with this string as it's value, but the string always gets cut off at about 83K - I attempted using both the nodeValue property, and by creating a new DOMTextNode. Reproduce code: --- To replicate, create a string that is greater than 83K (or so) - wholeText; ?> The echo'd value will be cut off at about 83K Expected result: Is there a reason for the limitation? - Or, is this a bug? -- Edit bug report at http://bugs.php.net/?id=46987&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46987&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46987&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46987&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46987&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46987&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46987&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46987&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46987&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46987&r=support Expected behavior: http://bugs.php.net/fix.php?id=46987&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46987&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46987&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46987&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46987&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46987&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46987&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46987&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46987&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46987&r=mysqlcfg
#46975 [Fbk->Opn]: checking for mysql_config... not found
ID: 46975 User updated by: support at silverservers dot com Reported By: support at silverservers dot com -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: CentOS 5.2 PHP Version: 5.2.8 Assigned To: mysql New Comment: I just tried that and yes, the config seems to have run successfully. I must have spent an hour trying to find the right way to do this... I've read postings that suggest others have the same issue. If the --with-mysql=/usr/local/mysql cannot be followed, can someone post the --with-pdo-mysql=shared,/usr/local/mysql to the configure and install instructions? Previous Comments: [2009-01-01 10:35:35] j...@php.net Doesn't this work: --with-pdo-mysql=shared,/usr/local/mysql [2008-12-30 19:10:39] support at silverservers dot com Description: Configure PHP with pdo_mysql fails using --pdo_mysql=shared "checking for mysql_config... not found" mysql_config exists and is "found" for other needs via --with-mysql=/usr/local/mysql configure for pdo does not seem to follow this path. TEMPORARY FIX is to symlink: ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config RESOLUTION: Best would be for pdo_mysql option to follow the path specified in --with-mysql ENVIRONMENT: CentOS 5.2 - source-compiled MySQL5.0.51/Apache1.3.41/PHP5.2.8 -- Edit this bug report at http://bugs.php.net/?id=46975&edit=1
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 Comment by: alex at peoples dot ru Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. Previous Comments: [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. [2008-12-31 14:35:13] hougiwro at guerrillamail dot org Why not just fix the bug so that existing installs can pick up a standard update without having to rebuild the program. Not everyone using PHP is necessarily comfortable with recompiling it in order to implement a workaround for a bug. [2008-12-31 13:37:17] phpbugs at colin dot guthr dot ie If you are on a shared host with a fixed PHP version then really the host should be responsible for deploying a well packaged version of PHP. If they are not doing that it is the host that is at fault and you should raise the issue with them. [2008-12-31 00:56:58] mark at mcclusky dot com I understand that there are workarounds to this bug, but for those of us on shared hosts that we can't recompile, this is a colossally frustrating state of affairs. Does anyone in PHP land have any timeline for a fix? [2008-12-29 17:02:44] jeffrey dot roberts at ibsgroup dot org For those as challenged as me at determining how to either downgrade libxml2 or recompile with libexpat while using cPANEL (easyapache), here is a link to the details. I confirm that after recompiling it is a workaround for the problem. http://blog.code-head.com/fixing-libxml-php-bug-and-issues-with-html-entities-libexpat First you will need to find out where libexpat is located on your server, it¡¯s probably here: /usr/lib To find out for sure, open this folder (/usr/lib) and look for the file: libexpat.so If you can¡¯t find it, log in as root via SSH and enter: whereis libexpat.so This should list the folder in which libexpat is located. After all this you will need to compile PHP to use libexpat instead of libxml, so go to: /var/cpanel/easy/apache/rawopts/ And create a file and name it ¡°all_php5¡å (no quotes), if there is a file with this name edit it and add these lines to the end of it: ¨Cwith-expat=builtin ¨Cwith-libexpat-dir=/usr/lib (lines start with two dashes ¡°-¡± that are not showing up here for some reason) Remember that depending on where libexpat is located on your server you might need to edit the second line. Now compile Apache and everything should work fine! The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#46954 [Opn->Bgs]: pg_prepare silently truncates query name
ID: 46954
Updated by: il...@php.net
Reported By: thuejk at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PostgreSQL related
Operating System: Linux
PHP Version: 5.2.8
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The truncation is done by Postgre and the PQPrepare() function does not
provide any indicators about truncation.
Previous Comments:
[2008-12-27 15:17:26] thuejk at gmail dot com
Description:
When using pg_prepare(string $stmtname, string $query) with a very long
$stmtname, the $stmtname will be silently truncated. It would be nice if
PHP emitted an E_NOTICE, as postgresql itself does:
psql=> PREPARE
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
as SELECT NOW();
NOTICE: identifier
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz"
will be truncated to
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijk"
PREPARE
Note that it is a sane idea to try to use the query itself as $stmtname
(less bookkeeping), which naturally leads to trying large $stmtname's.
Reproduce code:
---
pg_connect(...);
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
1", "SELECT 1");
pg_prepare("abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2", "SELECT 2");
Expected result:
An E_NOTICE because the name was truncated.
Actual result:
--
No E_NOTICE.
pg_prepare() [function.pg-prepare]: Query failed: ERROR: prepared
statement
"abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
2" already exists
--
Edit this bug report at http://bugs.php.net/?id=46954&edit=1
#46965 [Opn->WFx]: realpath_cache is disabled when safe_mode or open_basedir is enabled
ID: 46965
Updated by: il...@php.net
Reported By: phpbugs at bsdchicks dot com
-Status: Open
+Status: Wont fix
Bug Type: Safe Mode/open_basedir
Operating System: *
PHP Version: 5.2.8
New Comment:
Real path cache would make some checks unreliable. If you are using
SuExec or FastCGI you don't need open_basedir, you can use file system
permissions to implement access limitations much faster & more
reliably.
Previous Comments:
[2008-12-29 21:16:36] phpbugs at bsdchicks dot com
Description:
Having a lot of performance issues on FreeBSD caused an investigation
into realpath_cache. It turns out the cache is disabled when safe mode
or open basedir are enabled. However, in a client's configuration, with
FastCGI and SuExec, realpath_cache poses no security threat. With this
cache, performance is greatly improved.
It should be optional to override the decision to disable the cache.
Reproduce code:
---
/* Disable realpath cache if safe_mode or open_basedir are set */
if (PG(safe_mode) || (PG(open_basedir) && *PG(open_basedir))) {
CWDG(realpath_cache_size_limit) = 0;
}
Expected result:
N/A
Actual result:
--
N/A
--
Edit this bug report at http://bugs.php.net/?id=46965&edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: If the Fedora packages do not work then this is a RedHat packaging problem and you should complain to them/open a bug etc. etc. Like I say, in Mandriva we made sure we provided packages that worked because they were compiled with expat. Previous Comments: [2009-01-01 19:31:49] alex at peoples dot ru Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. [2008-12-31 14:35:13] hougiwro at guerrillamail dot org Why not just fix the bug so that existing installs can pick up a standard update without having to rebuild the program. Not everyone using PHP is necessarily comfortable with recompiling it in order to implement a workaround for a bug. [2008-12-31 13:37:17] phpbugs at colin dot guthr dot ie If you are on a shared host with a fixed PHP version then really the host should be responsible for deploying a well packaged version of PHP. If they are not doing that it is the host that is at fault and you should raise the issue with them. [2008-12-31 00:56:58] mark at mcclusky dot com I understand that there are workarounds to this bug, but for those of us on shared hosts that we can't recompile, this is a colossally frustrating state of affairs. Does anyone in PHP land have any timeline for a fix? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996&edit=1
#46844 [Ctl->Csd]: First line of included files not output if they begin with #
ID: 46844 Updated by: il...@php.net Reported By: phildrisc...@php.net -Status: Critical +Status: Closed Bug Type: Scripting Engine problem Operating System: Ubuntu Gutsy PHP Version: 5.3.0alpha3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-12-29 12:52:01] johan...@php.net That should be fixed for 5.3. [2008-12-17 02:45:55] j...@php.net I was kinda hoping it was some CLI/CGI thing only. :) [2008-12-16 18:41:52] phildrisc...@php.net Yes Jani - my test setup has PHP compiled as an Apache2 module. [2008-12-16 18:20:41] j...@php.net I can reproduce this with CLI and CGI, but does it happen also with f.e. Apache SAPIs? [2008-12-12 11:51:56] phildrisc...@php.net Description: 5.3.0alpha3 does not output the first line of an included script if the line begins with #. Earlier versions of PHP (prior to 5.3.0alpha1) do output first lines beginning with #. Reproduce code: --- test.php test.inc #1 #2 #3 Expected result: #1 #2 #3 Actual result: -- #2 #3 -- Edit this bug report at http://bugs.php.net/?id=46844&edit=1
#46844 [Csd->Opn]: First line of included files not output if they begin with #
ID: 46844 Updated by: nlop...@php.net Reported By: phildrisc...@php.net -Status: Closed +Status: Open Bug Type: Scripting Engine problem Operating System: Ubuntu Gutsy PHP Version: 5.3.0alpha3 New Comment: reopen, the bug is still alive. just change test.inc to #!1 ... Previous Comments: [2009-01-01 20:19:46] il...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2008-12-29 12:52:01] johan...@php.net That should be fixed for 5.3. [2008-12-17 02:45:55] j...@php.net I was kinda hoping it was some CLI/CGI thing only. :) [2008-12-16 18:41:52] phildrisc...@php.net Yes Jani - my test setup has PHP compiled as an Apache2 module. [2008-12-16 18:20:41] j...@php.net I can reproduce this with CLI and CGI, but does it happen also with f.e. Apache SAPIs? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46844 -- Edit this bug report at http://bugs.php.net/?id=46844&edit=1
#46985 [Fbk]: ZIP can not produce valid archive
ID: 46985
Updated by: paj...@php.net
Reported By: killerbg at gmail dot com
Status: Feedback
Bug Type: Zip Related
Operating System: Windows XP Professional SP3
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please try a 5.2 snapshot, I committed a fix that should fix this
issue.
Previous Comments:
[2009-01-01 16:25:38] killerbg at gmail dot com
pajoye(at)php(dot)net, here is the output from your script
http://rapidshare.com/files/178740823/ouput.zip.html
(identical with the two versions)
The file working state is the same as with my script
The php(at)undoso(dot)eu's solution is working here too
when combining php5ts.dll version 5.2.9 (CVS)
with php_zip.dll version 5.2.7 (CVS)
[2009-01-01 14:44:00] php at undoso dot eu
I have the same issue. It seems that compressing short strings works
fine but using huge ones gets them corrupted. Even if the resulting zip
might open, using a simple md5 on both files often prove that they
differs which is not great...
I downloaded PHP 5.2.6 and replaced the php_zip.dll of 5.2.8 by the
5.2.6 version. It fixed the problem right away. There is really some
kind of regression in 5.2.8.
[2009-01-01 00:38:55] paj...@php.net
It works just fine here (in apache2 sapi, iis, fcgi and cli).
Can you try the following script please? I suspect some other errors
happening and they are not displayed. Be sure to have display_errors
activated.
By the way, in the latest releases there are "addFromPattern"/"Glob"
functions which let you add recursively something like "*.jpeg" :)
addEmptyDir($local . $file . "/");
archive($path . $file . "/", $local .
$file . "/");
} elseif (is_file($path . $file)) {
if ($count > 128) {
$zip->close();
$zip->open($GLOBALS["file"]);
$count = 0;
}
$zip->addFile($path . $file, $local .
$file);
$count++;
}
}
}
closedir($handle);
}
echo "count: $count\n";
}
$file = 't.zip';
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::CREATE)) === TRUE) {
archive($path, null);
$zip->close();
}
echo "done\n";
[2008-12-31 23:12:49] killerbg at gmail dot com
Here is an archive containing both the corrupted file created with the
new versions, a good file created with the same script and older version
(5.2.6) and the script used -
http://rapidshare.com/files/178582253/Error.zip.html
[2008-12-31 21:21:33] paj...@php.net
I can't reproduce it here (xp sp3 and vista/2k8).
Please provide the file(s) (the minimum required to create a corrupted
archive) and the script you are using.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46985
--
Edit this bug report at http://bugs.php.net/?id=46985&edit=1
#46985 [Com]: ZIP can not produce valid archive
ID: 46985
Comment by: killerbg at gmail dot com
Reported By: killerbg at gmail dot com
Status: Feedback
Bug Type: Zip Related
Operating System: Windows XP Professional SP3
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
Now everything is working fine. Thank you very much!
Previous Comments:
[2009-01-01 20:42:18] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please try a 5.2 snapshot, I committed a fix that should fix this
issue.
[2009-01-01 16:25:38] killerbg at gmail dot com
pajoye(at)php(dot)net, here is the output from your script
http://rapidshare.com/files/178740823/ouput.zip.html
(identical with the two versions)
The file working state is the same as with my script
The php(at)undoso(dot)eu's solution is working here too
when combining php5ts.dll version 5.2.9 (CVS)
with php_zip.dll version 5.2.7 (CVS)
[2009-01-01 14:44:00] php at undoso dot eu
I have the same issue. It seems that compressing short strings works
fine but using huge ones gets them corrupted. Even if the resulting zip
might open, using a simple md5 on both files often prove that they
differs which is not great...
I downloaded PHP 5.2.6 and replaced the php_zip.dll of 5.2.8 by the
5.2.6 version. It fixed the problem right away. There is really some
kind of regression in 5.2.8.
[2009-01-01 00:38:55] paj...@php.net
It works just fine here (in apache2 sapi, iis, fcgi and cli).
Can you try the following script please? I suspect some other errors
happening and they are not displayed. Be sure to have display_errors
activated.
By the way, in the latest releases there are "addFromPattern"/"Glob"
functions which let you add recursively something like "*.jpeg" :)
addEmptyDir($local . $file . "/");
archive($path . $file . "/", $local .
$file . "/");
} elseif (is_file($path . $file)) {
if ($count > 128) {
$zip->close();
$zip->open($GLOBALS["file"]);
$count = 0;
}
$zip->addFile($path . $file, $local .
$file);
$count++;
}
}
}
closedir($handle);
}
echo "count: $count\n";
}
$file = 't.zip';
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::CREATE)) === TRUE) {
archive($path, null);
$zip->close();
}
echo "done\n";
[2008-12-31 23:12:49] killerbg at gmail dot com
Here is an archive containing both the corrupted file created with the
new versions, a good file created with the same script and older version
(5.2.6) and the script used -
http://rapidshare.com/files/178582253/Error.zip.html
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46985
--
Edit this bug report at http://bugs.php.net/?id=46985&edit=1
#46347 [Asn]: parse_ini_file() does not like asterisk (*) in key
ID: 46347 Updated by: nlop...@php.net Reported By: duke at masendav dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3CVS-2008-11-11 Assigned To: scottmac New Comment: jani: try [*] or "*" to match a single '*' char Previous Comments: [2009-01-01 11:57:00] j...@php.net I don't know how to allow literal * in re2c. (\* did not work) And I don't have spare time to debug this. Ask Pierre if he has. [2008-12-24 13:58:39] scott...@php.net Jani, this wasn't broken by any of the re2c stuff. The changes you made to zend_ini_scanner.l revision 1.48 are the cause. [2008-10-20 21:01:03] duke at masendav dot com More like undocumented feature then. Nothing at http://www.php.net/parse_ini_file says that * cannot be used inside keys. So we are using it in a few in-house applications and this came as unpleasant surprise. We can of course implement a different solution, if you really consider the current (5.2) behaviour bug. In which case it would be nice to have a better explanation in parse_ini_file documentation with regard to what is considered a valid syntax and what not. [2008-10-20 20:45:16] j...@php.net Why should it like it? That looks like a bug that got fixed by the new parser. [2008-10-20 19:40:21] duke at masendav dot com Description: parse_ini_file no longer likes * (asterisk) in configuration keys. Works just fine in PHP 5.2.5 Reproduce code: --- Ini file with the following content: [section] part1.*.part2 = 1 PHP file: http://bugs.php.net/?id=46347&edit=1
#46975 [Opn->Asn]: checking for mysql_config... not found
ID: 46975 Updated by: ka...@php.net Reported By: support at silverservers dot com -Status: Open +Status: Assigned Bug Type: PHP options/info functions Operating System: CentOS 5.2 PHP Version: 5.2.8 Assigned To: mysql Previous Comments: [2009-01-01 17:57:30] support at silverservers dot com I just tried that and yes, the config seems to have run successfully. I must have spent an hour trying to find the right way to do this... I've read postings that suggest others have the same issue. If the --with-mysql=/usr/local/mysql cannot be followed, can someone post the --with-pdo-mysql=shared,/usr/local/mysql to the configure and install instructions? [2009-01-01 10:35:35] j...@php.net Doesn't this work: --with-pdo-mysql=shared,/usr/local/mysql [2008-12-30 19:10:39] support at silverservers dot com Description: Configure PHP with pdo_mysql fails using --pdo_mysql=shared "checking for mysql_config... not found" mysql_config exists and is "found" for other needs via --with-mysql=/usr/local/mysql configure for pdo does not seem to follow this path. TEMPORARY FIX is to symlink: ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config RESOLUTION: Best would be for pdo_mysql option to follow the path specified in --with-mysql ENVIRONMENT: CentOS 5.2 - source-compiled MySQL5.0.51/Apache1.3.41/PHP5.2.8 -- Edit this bug report at http://bugs.php.net/?id=46975&edit=1
#46988 [NEW]: 2 requests: Closures Recursion & __callFunction
From: info at netmosfera dot it
Operating system:
PHP version: 5.3.0alpha3
PHP Bug Type: Feature/Change Request
Bug description: 2 requests: Closures Recursion & __callFunction
Description:
hello, i have two requests for next releases of php
like __call & __callStatic, __callFunction... for dynamic function
overloading
and recursion for closures
Reproduce code:
---
function __callFunction($funcname, Array $arguments)
{
echo $funcname;
}
notDefined();
---
function($increment) use ($i = 0)
{
// code here
// code here
echo ++$increment;
if ($increment==20) return;
function use($increment);
};
alternative syntax:
recursion use($increment);
--
Edit bug report at http://bugs.php.net/?id=46988&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46988&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46988&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46988&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46988&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46988&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46988&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46988&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46988&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46988&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46988&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46988&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46988&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46988&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46988&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46988&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46988&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46988&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46988&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46988&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46988&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46988&r=mysqlcfg
#46974 [Com]: Closure and Namespaces bug! FATAL ERROR
ID: 46974
Comment by: info at netmosfera dot it
Reported By: info at netmosfera dot it
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0alpha3
Assigned To: stas
New Comment:
hi, thanks for accepting this bug
i have one request, is possible to make autoloads for namespaces?
is this back compatible?
namespace a
{
function __autoload(){echo "a";}
new Pippo();
}
namespace b
{
function __autoload(){echo "b";}
new Pippo();
}
thank you
Previous Comments:
[2008-12-30 17:19:24] info at netmosfera dot it
ok, with __autoload in global namespace works
if you remove the closure but works too
where's the problem?
[2008-12-30 16:50:06] info at netmosfera dot it
uhm... autoload is not called!
another suggest:
Closure is a special class\type
so it must be global
in a namespace i have to use
public function method(\Closure $x){}
instead of
public function method(Closure $x){}
is it correct? Closure is a special type and final too
[2008-12-30 16:40:22] info at netmosfera dot it
Description:
hi,
i noticed there is a bug that causes a FATAL ERROR
please read the code
thank you for your time
Reproduce code:
---
file index.php:
file Clsure-Testing.php:
Actual result:
--
Fatal error: Class 'Clsure\Testing' not found in on line 12
--
Edit this bug report at http://bugs.php.net/?id=46974&edit=1
#46989 [NEW]: namespace fallback for classes
From: info at netmosfera dot it Operating system: irrelevant PHP version: 5.3.0alpha3 PHP Bug Type: Feature/Change Request Bug description: namespace fallback for classes Description: hello is possible to implement classes fallback in php namespaces? thank you Reproduce code: --- namespace A\B\C; new X(); A\B\C\Exception not found, switch to A\B\Exception not found, switch to A\Exception not found, switch to \Exception found -- Edit bug report at http://bugs.php.net/?id=46989&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46989&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46989&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46989&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46989&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46989&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46989&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46989&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46989&r=support Expected behavior: http://bugs.php.net/fix.php?id=46989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46989&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46989&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46989&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46989&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46989&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46989&r=mysqlcfg
#46867 [Opn->Bgs]: "use...as" not suppored by Reflection::export()
ID: 46867 Updated by: johan...@php.net Reported By: naturallydigital at yahoo dot com -Status: Open +Status: Bogus Bug Type: Reflection related Operating System: * PHP Version: 5.3CVS-2008-12-15 (CVS) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php In strins you always have to use the fully qualified name - we don't know where the string is coming from and the aliasing is done at compile time,not runtime ... Previous Comments: [2009-01-01 02:15:18] ka...@php.net Should be same with class_alias(), I'm not sure if its intended for Reflection to support aliased classes [2008-12-15 08:27:00] naturallydigital at yahoo dot com Description: The Reflection API does not support the "use... as... " syntax for namespaces in 5.3 CVS. I ran the raw unzipped Win32 VC6 snapshot from snaps.php.net: "php -c php.ini-dist d:\reflect.php" (code below) Reproduce code: --- getMessage(); } ?> Expected result: User class C (a.k.a. D) reflected in the Command Prompt window. Actual result: -- "Class D does not exist" output in the Command Prompt window. -- Edit this bug report at http://bugs.php.net/?id=46867&edit=1
#46975 [Asn->Bgs]: checking for mysql_config... not found
ID: 46975 Updated by: johan...@php.net Reported By: support at silverservers dot com -Status: Assigned +Status: Bogus Bug Type: PHP options/info functions Operating System: CentOS 5.2 PHP Version: 5.2.8 Assigned To: mysql New Comment: This is a geneal thing, MySQL and PDO independent. From ./configure --help: Extensions: --with-EXTENSION=shared[,PATH] NOTE: Not all extensions can be build as 'shared'. Example: --with-foobar=shared,/usr/local/foobar/ o Builds the foobar extension as shared extension. o foobar package install prefix is /usr/local/foobar/ Previous Comments: [2009-01-01 17:57:30] support at silverservers dot com I just tried that and yes, the config seems to have run successfully. I must have spent an hour trying to find the right way to do this... I've read postings that suggest others have the same issue. If the --with-mysql=/usr/local/mysql cannot be followed, can someone post the --with-pdo-mysql=shared,/usr/local/mysql to the configure and install instructions? [2009-01-01 10:35:35] j...@php.net Doesn't this work: --with-pdo-mysql=shared,/usr/local/mysql [2008-12-30 19:10:39] support at silverservers dot com Description: Configure PHP with pdo_mysql fails using --pdo_mysql=shared "checking for mysql_config... not found" mysql_config exists and is "found" for other needs via --with-mysql=/usr/local/mysql configure for pdo does not seem to follow this path. TEMPORARY FIX is to symlink: ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config RESOLUTION: Best would be for pdo_mysql option to follow the path specified in --with-mysql ENVIRONMENT: CentOS 5.2 - source-compiled MySQL5.0.51/Apache1.3.41/PHP5.2.8 -- Edit this bug report at http://bugs.php.net/?id=46975&edit=1
#46944 [Ver->Csd]: json_encode chokes on characters outside the BMP
ID: 46944
Updated by: scott...@php.net
Reported By: anomie at users dot sourceforge dot net
-Status: Verified
+Status: Closed
Bug Type: JSON related
Operating System: Linux
PHP Version: 5.3CVS-2008-12-26 (snap)
Assigned To: scottmac
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-12-26 15:39:44] anomie at users dot sourceforge dot net
Description:
json_encode encodes characters above U+1 incorrectly; sometimes it
incorrectly encodes them as characters in the U+1-U+1 range, and
sometimes it just errors out.
Note this is not an error with the source not being UTF8; as you can
see below, I am building the UTF8-encoded text byte-by-byte.
5.2.6 has the same problem, although instead of null it returns "aa"
for those cases due to bug 43941.
It looks like there are actually two unrelated bugs here:
1. utf8_to_utf16 in ext/json/utf8_to_utf16.c should use "c -= 0x1;"
at line 49 instead of "c &= 0x;". This causes the part where it
incorrectly encodes values over U+1 as U+1-U+1.
2. utf8_decode_next in ext/json/utf8_decode.c should use 0xF8 instead
of 0xF1 at line 168. This causes the part where UTF8 characters
beginning with an F1 or F3 byte error out.
Reproduce code:
---
for($i=1; $i<=16; $i++){
print
json_encode("aa".chr(0xf0|($i>>2)).chr(0x8f|($i&3)<<4)."\xbf\xbdzz")."\n";
}
Expected result:
"aa\ud83f\udffdzz"
"aa\ud87f\udffdzz"
"aa\ud8bf\udffdzz"
"aa\ud8ff\udffdzz"
"aa\ud93f\udffdzz"
"aa\ud97f\udffdzz"
"aa\ud9bf\udffdzz"
"aa\ud9ff\udffdzz"
"aa\uda3f\udffdzz"
"aa\uda7f\udffdzz"
"aa\udabf\udffdzz"
"aa\udaff\udffdzz"
"aa\udb3f\udffdzz"
"aa\udb7f\udffdzz"
"aa\udbbf\udffdzz"
"aa\udbff\udffdzz"
Actual result:
--
"aa\ud83f\udffdzz"
"aa\ud83f\udffdzz"
"aa\ud83f\udffdzz"
null
null
null
null
"aa\ud83f\udffdzz"
"aa\ud83f\udffdzz"
"aa\ud83f\udffdzz"
"aa\ud83f\udffdzz"
null
null
null
null
"aa\ud83f\udffdzz"
--
Edit this bug report at http://bugs.php.net/?id=46944&edit=1
#46347 [Asn->Opn]: parse_ini_file() does not like asterisk (*) in key
ID: 46347 Updated by: j...@php.net Reported By: duke at masendav dot com -Status: Assigned +Status: Open Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3CVS-2008-11-11 -Assigned To: jani +Assigned To: scottmac Previous Comments: [2008-12-24 13:58:39] scott...@php.net Jani, this wasn't broken by any of the re2c stuff. The changes you made to zend_ini_scanner.l revision 1.48 are the cause. [2008-10-20 21:01:03] duke at masendav dot com More like undocumented feature then. Nothing at http://www.php.net/parse_ini_file says that * cannot be used inside keys. So we are using it in a few in-house applications and this came as unpleasant surprise. We can of course implement a different solution, if you really consider the current (5.2) behaviour bug. In which case it would be nice to have a better explanation in parse_ini_file documentation with regard to what is considered a valid syntax and what not. [2008-10-20 20:45:16] j...@php.net Why should it like it? That looks like a bug that got fixed by the new parser. [2008-10-20 19:40:21] duke at masendav dot com Description: parse_ini_file no longer likes * (asterisk) in configuration keys. Works just fine in PHP 5.2.5 Reproduce code: --- Ini file with the following content: [section] part1.*.part2 = 1 PHP file: http://bugs.php.net/?id=46347&edit=1
#46985 [Fbk->Csd]: ZIP can not produce valid archive
ID: 46985
Updated by: paj...@php.net
Reported By: killerbg at gmail dot com
-Status: Feedback
+Status: Closed
Bug Type: Zip Related
Operating System: Windows XP Professional SP3
PHP Version: 5.2.8
Assigned To: pajoye
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed in 5.2, 5.3, head.
Previous Comments:
[2009-01-01 21:29:47] killerbg at gmail dot com
Now everything is working fine. Thank you very much!
[2009-01-01 20:42:18] paj...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please try a 5.2 snapshot, I committed a fix that should fix this
issue.
[2009-01-01 16:25:38] killerbg at gmail dot com
pajoye(at)php(dot)net, here is the output from your script
http://rapidshare.com/files/178740823/ouput.zip.html
(identical with the two versions)
The file working state is the same as with my script
The php(at)undoso(dot)eu's solution is working here too
when combining php5ts.dll version 5.2.9 (CVS)
with php_zip.dll version 5.2.7 (CVS)
[2009-01-01 14:44:00] php at undoso dot eu
I have the same issue. It seems that compressing short strings works
fine but using huge ones gets them corrupted. Even if the resulting zip
might open, using a simple md5 on both files often prove that they
differs which is not great...
I downloaded PHP 5.2.6 and replaced the php_zip.dll of 5.2.8 by the
5.2.6 version. It fixed the problem right away. There is really some
kind of regression in 5.2.8.
[2009-01-01 00:38:55] paj...@php.net
It works just fine here (in apache2 sapi, iis, fcgi and cli).
Can you try the following script please? I suspect some other errors
happening and they are not displayed. Be sure to have display_errors
activated.
By the way, in the latest releases there are "addFromPattern"/"Glob"
functions which let you add recursively something like "*.jpeg" :)
addEmptyDir($local . $file . "/");
archive($path . $file . "/", $local .
$file . "/");
} elseif (is_file($path . $file)) {
if ($count > 128) {
$zip->close();
$zip->open($GLOBALS["file"]);
$count = 0;
}
$zip->addFile($path . $file, $local .
$file);
$count++;
}
}
}
closedir($handle);
}
echo "count: $count\n";
}
$file = 't.zip';
$zip = new ZipArchive();
if (($zip->open($file, ZipArchive::CREATE)) === TRUE) {
archive($path, null);
$zip->close();
}
echo "done\n";
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46985
--
Edit this bug report at http://bugs.php.net/?id=46985&edit=1
