Bug #49013 [Com]: SOAPClient interprets the parameters array incorrectly
Edit report at https://bugs.php.net/bug.php?id=49013&edit=1
ID: 49013
Comment by: cwei...@php.net
Reported by:egos at biz-club dot biz
Summary:SOAPClient interprets the parameters array
incorrectly
Status: Re-Opened
Type: Bug
Package:SOAP related
Operating System: debian Lenny
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
I meant PHP 5.5.1, not 5.1.
Previous Comments:
[2013-09-04 13:54:14] cwei...@php.net
We can reproduce the issue on PHP 5.1, see the files at http://p.cweiske.de/53:
SoapClient: http://p.cweiske.de/53/raw/soapclienttest.php
WSDL: http://p.cweiske.de/53/raw/test.wsdl
We give an associative array of parameters:
$arguments = array(
'password' => 'password-value',
'username' => 'username-value',
);
But the SOAP request has the values in wrong order:
password-value
username-value
[2009-08-11 01:00:00] 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-08-03 15:17:46] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-07-22 07:20:03] egos at biz-club dot biz
Description:
on Debian Lenny (php 5.2.6.dfsg.1-1+lenny3) i run the simple call.
please, take a look at var_dump of the parameters variable and at the generated
xml code
Before xml is generated, it sorts the parameters, so that values loose bindings
to the keys of the array.
Reproduce code:
---
$client->__soapCall("updateMonitoring", $parameters);
var_dump($parameters);
echo "";
echo " REQUEST:\n" . $client->__getLastRequest() . "\n";
Expected result:
correct xml, based on $parameters. Here,s the var_dump of it $parameters I put
there
["login"]=>
string(4) "***"
["password"]=>
string(32) "***"
["monitoring_id"]=>
string(5) "18700"
["plan_budget_total"]=>
string(2) "70"
["plan_budget_navigation"]=>
string(1) "0"
["plan_pay"]=>
string(2) "25"
["total"]=>
int(66)
["task_training"]=>
int(0)
["without_preliminary_examination"]=>
int(0)
["without_competition"]=>
int(0)
["city_0_59"]=>
int(0)
["city_60_100"]=>
int(0)
["city_101_110"]=>
int(0)
["city_111_120"]=>
int(0)
["city_121_130"]=>
int(0)
["city_131_140"]=>
int(0)
["city_141_150"]=>
int(1)
["city_151_160"]=>
int(1)
["city_161_170"]=>
int(2)
["city_171_180"]=>
int(0)
["city_181_190"]=>
int(2)
["city_191_200"]=>
int(2)
["city_201_210"]=>
int(5)
["city_211_220"]=>
int(3)
["city_221_230"]=>
int(1)
["city_231_240"]=>
int(8)
["city_241_250"]=>
int(1)
["city_251_260"]=>
int(4)
["city_261_270"]=>
int(2)
["city_271_280"]=>
int(5)
["city_281_290"]=>
int(5)
["city_291_300"]=>
int(3)
["city_301_310"]=>
int(10)
["city_311_320"]=>
int(3)
["city_321_330"]=>
int(2)
["city_331_340"]=>
int(2)
["city_341_400"]=>
int(1)
["country_0_59"]=>
int(0)
["country_60_100"]=>
int(0)
["country_101_110"]=>
int(0)
["country_111_120"]=>
int(0)
["country_121_130"]=>
int(0)
["country_131_140"]=>
int(0)
["country_141_150"]=>
int(0)
["country_151_160"]=>
int(0)
["country_161_170"]=>
int(0)
["country_171_180"]=>
int(0)
["country_181_190"]=>
int(0)
["country_191_200"]=>
int(0)
["country_201_210"]=>
int(1)
["country_211_220"]=>
int(1)
["country_221_230"]=>
int(0)
["country_231_240"]=>
int(0)
["country_241_250"]=>
int(1)
["country_251_
[PHP-BUG] Bug #64589 [NEW]: SOAP arrays with non-sequentially indexed keys ignored
From: cweiske Operating system: Linux PHP version: 5.5.0beta1 Package: SOAP related Bug Type: Bug Bug description:SOAP arrays with non-sequentially indexed keys ignored Description: When passing a non-sequentially numerically indexed array to a SOAPClient method, it gets ignored as "empty". Test script: --- http://p.cweiske.de/35 Expected result: foo foo2 Actual result: -- -- Edit bug report at https://bugs.php.net/bug.php?id=64589&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64589&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64589&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64589&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64589&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64589&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64589&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64589&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64589&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64589&r=support Expected behavior: https://bugs.php.net/fix.php?id=64589&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64589&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64589&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64589&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64589&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64589&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64589&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64589&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64589&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64589&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64589&r=mysqlcfg
Bug #48795 [Com]: Building intl 64-bit fails on OS X
Edit report at https://bugs.php.net/bug.php?id=48795&edit=1 ID: 48795 Comment by: cwei...@php.net Reported by:gwy...@php.net Summary:Building intl 64-bit fails on OS X Status: Verified Type: Bug Package:Compile Failure Operating System: OS X 10.5 & 10.6; Linux PHP Version:5.3 SVN; 5.4.0RC1 Block user comment: N Private report: N New Comment: Still happens on 5.3.26. cornelius dot howl at gmail dot com's commands do not help here. Previous Comments: [2013-03-09 10:14:47] cornelius dot howl at gmail dot com For this issue, here is the patch in phpbrew https://github.com/c9s/phpbrew/commit/18ef766d0e013ee87ac7d86e338ebec89fbeb445 [2013-03-09 10:12:31] cornelius dot howl at gmail dot com Quick fix for this 5.3.28 should work edit Makefile and found the rule of ext/intl/msgformat/msgformat_helpers.cpp change the $(CC) to $(CXX) then run: sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile [2013-03-08 16:27:05] saltwaterc at gmail dot com sed -i '/EXTRA_LIBS = /s|$| -lstdc++|' Makefile One liner fix for those who still do (scripted) builds on 5.3.x. 5.3.22 still fails on Ubuntu 12.04. [2012-10-26 02:59:59] pgarvin76 at gmail dot com This is still and issue on 5.3.18, but 5.4.8 built without error. Interestingly if you build intl as shared you don't get the compile error (how I am currently getting around issue). I am on Ubuntu 12.04. [2012-09-11 16:27:47] re...@php.net Same for me, I can't compile either. hope there is a solution 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 https://bugs.php.net/bug.php?id=48795 -- Edit this bug report at https://bugs.php.net/bug.php?id=48795&edit=1
#48221 [NEW]: memory leak when passing invalid xslt parameter
From: cwei...@php.net
Operating system: Linux
PHP version: 5.3.0RC2
PHP Bug Type: XSLT related
Bug description: memory leak when passing invalid xslt parameter
Description:
One is able to pass invalid parameters to XSLTProcessor::setParameter. In
this case, not all memory gets freed in
ext/xsl/xsltprocessor.c::php_xsl_xslt_make_params since the values don't
get filled and the array seems to be empty (NULL values).
Reproduce code:
---
--TEST--
Check xsltprocessor::setparameter error handling with both single and
double quotes
--SKIPIF--
--FILE--
importStylesheet($xsl);
$proc->setParameter('', '', '"\'');
$proc->transformToXml($dom);
--EXPECTF--
Warning: XSLTProcessor::transformToXml(): Cannot create XPath expression
(string contains both
--CREDITS--
Christian Weiske, cwei...@php.net
PHP Testfest Berlin 2009-05-09
Actual result:
--
[Sun May 10 15:20:40 2009] Script:
'/home/cweiske/Dev/cvs/php/testfest/tests/xsl/php_xsl_xslt_string_to_xpathexpr.php'
/home/cweiske/Dev/cvs/php/php-5.3.0RC2/Zend/zend_hash.c(1118) : Freeing
0x0188D558 (1 bytes),
script=/home/cweiske/Dev/cvs/php/testfest/tests/xsl/php_xsl_xslt_string_to_xpathexpr.php
=== Total 1 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/?id=48221&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48221&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48221&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48221&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48221&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48221&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48221&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48221&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48221&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48221&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48221&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48221&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48221&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48221&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48221&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48221&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48221&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48221&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48221&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48221&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48221&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48221&r=mysqlcfg
#50159 [NEW]: wrong working directory in symlinked files
From: cwei...@php.net Operating system: PHP version: 5.3.1RC3 PHP Bug Type: *General Issues Bug description: wrong working directory in symlinked files Description: getcwd() and the current working directory does not work correctly anymore on php 5.3.0 and 5.3.1RCx when executing a symlinked file. In php versions before 5.3.0, the current working directory of a file was the directory below the document root of the web server. in 5.3.0, it's the target directory of the symlinked file. Imagine the following file layout: /var/www/host/ - webserver document root /var/www/host/config.php /var/www/host/index.php - symlink to /usr/share/app/index.php When opening index.php, getcwd() returns /usr/share/app/ in 5.3.0 and 5.3.1rc(1|2|3), while it returned /var/www/host/ on 5.2.x. This change causes real problems because now it is impossible to share application code easily among installations! -- Edit bug report at http://bugs.php.net/?id=50159&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50159&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50159&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50159&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50159&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50159&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50159&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50159&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50159&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50159&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50159&r=support Expected behavior: http://bugs.php.net/fix.php?id=50159&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50159&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50159&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50159&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50159&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50159&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50159&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50159&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50159&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50159&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50159&r=mysqlcfg
#47396 [NEW]: resource ids get re-used when opening enough files
From: cwei...@php.net Operating system: PHP version: 5.2.9RC2 PHP Bug Type: Reproducible crash Bug description: resource ids get re-used when opening enough files Description: Using php for long running daemons and opening files in there can lead to crashes, when resource ids wrap around the integer/long size and come to 0 at last. There is no sanity check if a resource is already in use when assigning it. This problem is more likely to appear on 32bit systems than on 64, since it takes ages to overflow that number with 64bit. Still, it is a problem. Example: - Open a file -> resource id is now +1 - Open many files. Eventually, it will reach MAX_INT or whatever number that is and wrap around to "-" that number, increasing from now on. - Double the time, and the script reaches an resource id of 0 - Now chances are very high that the an existing resource is at the same id - PHP crashes The problem has been - wrongly - described here: http://gnuvince.wordpress.com/2008/10/28/php-wrong-for-long-running-processes-wrong-for-america/ The issue is the one I described here -- Edit bug report at http://bugs.php.net/?id=47396&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47396&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47396&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47396&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47396&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47396&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47396&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47396&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47396&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47396&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47396&r=support Expected behavior: http://bugs.php.net/fix.php?id=47396&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47396&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47396&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47396&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47396&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47396&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47396&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47396&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47396&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47396&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47396&r=mysqlcfg
[PHP-BUG] Bug #55124 [NEW]: recursive mkdir fails with current (dot) directory in path
From: cweiske
Operating system:
PHP version: 5.3.6
Package: Directory function related
Bug Type: Bug
Bug description:recursive mkdir fails with current (dot) directory in path
Description:
Running recursive mkdir fails when there is a "." directory in the path:
PHP Warning: mkdir(): File exists in Command line code on line 1
Warning: mkdir(): File exists in Command line code on line 1
When a does not exist, "a" is generated, but "b" is not.
When a exists already, everything is fine.
Note that I cannot use realpath() to sanitize the path because the path
does not exist yet.
Test script:
---
Actual result:
--
$ /opt/phpfarm/inst/bin/php-5.3.6 -v
PHP 5.3.6 (cli) (built: Mar 18 2011 09:27:59) (DEBUG)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
$ LC_ALL=C ls a
ls: cannot access a: No such file or directory
$ /opt/phpfarm/inst/bin/php-5.3.6 -r 'mkdir("a/./b", 0755, true);'
PHP Warning: mkdir(): File exists in Command line code on line 1
Warning: mkdir(): File exists in Command line code on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=55124&edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55124&r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55124&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55124&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55124&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55124&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55124&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55124&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55124&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55124&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55124&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55124&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55124&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55124&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55124&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55124&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55124&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55124&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55124&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55124&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55124&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55124&r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55124&r=trysnapshot54
[PHP-BUG] Req #55458 [NEW]: variables_order should contain E by default
From: cweiske Operating system: PHP version: 5.3.7 Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:variables_order should contain E by default Description: The default php.ini-production[1] sets variables_order to "GPCS", which misses the "E" for environment variables. This change was introduced in revision 277363 on Tue Mar 17 19:19:17 2009 by johannes: > MFH: Replace old php.ini files with the new ones according to > http://wiki.php.net/rfc/newinis (by Eric Lee Stewart) The wiki page writes: > There is a performance penalty paid for the registration of > these arrays and because ENV is not as commonly used as the > others, ENV is is not recommended on productions servers. Since superglobals are only registered when they are used by the code (JIT), there should not really be a performance penalty, and E should be included in the default production setting. [1] http://svn.php.net/viewvc/php/php-src/trunk/php.ini-production -- Edit bug report at https://bugs.php.net/bug.php?id=55458&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55458&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55458&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55458&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55458&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55458&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55458&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55458&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55458&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55458&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55458&r=support Expected behavior: https://bugs.php.net/fix.php?id=55458&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55458&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55458&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55458&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55458&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55458&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55458&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55458&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55458&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55458&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55458&r=mysqlcfg
Bug #54289 [Com]: Phar::extractTo() does not accept specific directories to be extracted
Edit report at https://bugs.php.net/bug.php?id=54289&edit=1
ID: 54289
Comment by: cwei...@php.net
Reported by:hpdl at oscommerce dot com
Summary:Phar::extractTo() does not accept specific
directories to be extracted
Status: Open
Type: Bug
Package:PHAR related
Operating System: MacOS 10.6.6
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
I can confirm that - extracting directories does not work:
PHP Fatal error: Uncaught exception 'PharException' with message
'Phar Error: attempted to extract non-existent file "doc/" from phar
"/home/cweiske/Dev/semanticscuttle/cwdev/dist/SemanticScuttle-0.98.X.phar"'
in /home/cweiske/Dev/semanticscuttle/cwdev/phartest.php:3
Stack trace:
#0 /home/cweiske/Dev/semanticscuttle/cwdev/phartest.php(3):
Phar->extractTo('/tmp/test/', 'doc/', true)
#1 {main}
thrown in /home/cweiske/Dev/semanticscuttle/cwdev/phartest.php on line 3
Previous Comments:
[2011-08-11 20:33:50] hpdl at oscommerce dot com
Bug still exists in PHP 5.3.7RC5.
[2011-03-17 10:44:06] hpdl at oscommerce dot com
Description:
Phar::extractTo() does not allow specific directories to be extracted. The
documentation states the second parameter can be a file or directory to only
extract the file or directory from the phar archive.
Specific files can be extracted however an exception is thrown when a directory
is
passed.
Test script:
---
buildFromDirectory('/path/to/source');
unset($phar);
$phar = new Phar('/tmp/test.phar');
$phar->extractTo('/tmp/test/', 'subdir1/subdir2/', true); // throws exception
// $phar->extractTo('/tmp/test/', 'subdir1/subdir2/file.txt', true); // works
as intended
?>
Expected result:
The specific directory should be extracted from the phar archive.
Actual result:
--
Fatal error: Uncaught exception 'PharException' with message 'Phar Error:
attempted to extract non-existent file "subdir1/subdir2/" from phar
"/tmp/test.phar"' in /phar-test.php on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=54289&edit=1
[PHP-BUG] Bug #55634 [NEW]: ./configure does not fail if invalid option is used
From: cweiske Operating system: PHP version: 5.3.8 Package: *Configuration Issues Bug Type: Bug Bug description:./configure does not fail if invalid option is used Description: When using ./configure --with-foo, configure tells me at the end: > Notice: Following unknown configure options were used: > --with-foo There are two problems: - This problem is echoed to stdout, not stderr where capturing it would be possible - The exit code is still 0, although I clearly issued a wrong option. In the end I cannot figure out if the configure run was *fully* successful. Expected result: 1. config option errors echoed to stderr 2. exit code of configure script != 0 -- Edit bug report at https://bugs.php.net/bug.php?id=55634&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55634&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55634&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55634&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55634&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55634&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55634&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55634&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55634&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55634&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55634&r=support Expected behavior: https://bugs.php.net/fix.php?id=55634&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55634&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55634&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55634&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55634&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55634&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55634&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55634&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55634&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55634&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55634&r=mysqlcfg
