Bug #53551 [Asn-Csd]: PDOStatement execute segfaults for pdo_mysql driver
Edit report at http://bugs.php.net/bug.php?id=53551edit=1
ID: 53551
Updated by: u...@php.net
Reported by:eddawley at gmail dot com
Summary:PDOStatement execute segfaults for pdo_mysql driver
-Status: Assigned
+Status: Closed
Type: Bug
Package:PDO related
Operating System: Centos 5
PHP Version:5.3.4
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
See SVN note
Previous Comments:
[2011-01-14 15:57:59] johan...@php.net
Automatic comment from SVN on behalf of johannes
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307478
Log: - Fix #53551 (PDOStatement execute segfaults for pdo_mysql driver)
[2011-01-06 12:03:48] u...@php.net
That fix should do it, however, I'd like to wait until Johannes returns
from vacation and reviews it. PDO is a bit of a beast. With the fix the
code should neither crash nor leak, nor behave differently from
PDO_SQlite. Anyway, the result is still pretty, well, PDOish weird:
error codes not cleaned up properly upon rebinding. Not my cup of
coffee...
Index: ext/pdo_mysql/mysql_statement.c
===
--- ext/pdo_mysql/mysql_statement.c (Revision 307155)
+++ ext/pdo_mysql/mysql_statement.c (Arbeitskopie)
@@ -141,10 +141,12 @@
/* (re)bind the parameters */
if (mysql_stmt_bind_param(S-stmt, S-params) ||
mysql_stmt_execute(S-stmt)) {
+ /*
if (S-params) {
efree(S-params);
S-params = 0;
}
+ */
pdo_mysql_error_stmt(stmt);
if (mysql_stmt_errno(S-stmt) == 2057) {
/* CR_NEW_STMT_METADATA makes the statement
unusable */
[2010-12-17 20:58:27] eddawley at gmail dot com
Sorry, I didn't realize I was being unclear. The segfault is occurring
with PDO
using libmysql.
Here are my relevant configure options:
'--with-mysql=mysqlnd' '--with-mysqli' '--with-pdo-mysql'
[2010-12-17 20:44:00] ka...@php.net
MySQLnd is not a driver, its a library backend. MySQL, MySQLi and
PDO_MySQL can all be powered by either libmysql or mysqlnd.
So what you are saying is that you built pdo_mysql against libmysql
which segfaults?
[2010-12-17 19:38:02] eddawley at gmail dot com
I would like to add that this happens for other mysql-level errors. For
example, the following will also cause a segfault when reused:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or
update a
child
row: a foreign key constraint fails ...
SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for
column...
And again, this was noticed with the pdo_mysql driver. NOT the mysqlnd
native
driver.
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/bug.php?id=53551
--
Edit this bug report at http://bugs.php.net/bug.php?id=53551edit=1
Bug #53287 [Fbk]: PDO 5 Byte write to a broken pipe when forked
Edit report at http://bugs.php.net/bug.php?id=53287edit=1
ID: 53287
Updated by: u...@php.net
Reported by:bryan dot tong at gigenet dot com
Summary:PDO 5 Byte write to a broken pipe when forked
Status: Feedback
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86-64
PHP Version:5.3SVN-2010-11-10 (snap)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
This does not smell like an error rather more like mysqlnd being more
verbose. No bug, a feature, I'd say.
Previous Comments:
[2010-12-05 21:23:46] seza at paradoxal dot org
I have the same error message with php.5.3.3 (send of 5 bytes failed
with errno=32 Broken pipe) but in a
different context more simply to reproduce :
I have a simple website (no fork or stuff like that). It make persistent
connection with pdo to mysql
(mysqlnd). The errors are raised when the mysql is server is restarted.
When mysql server is off error message are mysql server is gone away. No
problem with that but once the
mysql server is restarted and during 15 minutes I have sometimes this
error message (send of 5 bytes
failed with errno=32 Broken pipe).
Certainly a reuse of a cached connection to mysql before it was
restarted.
PS : I use mysql_sock connection
(mysql:unix_socket=/var/run/mysqld/mysqld.sock)
[2010-11-26 13:19:45] johan...@php.net
The description mentions forking, the sample code not. Please provide a
complete script showing the issue.
[2010-11-10 03:21:00] bryan dot tong at gigenet dot com
Description:
When switching from PHP 5.1.6 to PHP 5.3.3 the following notice has
begun to show up in our scripts.
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
We are running a daemon and the forked children throw this error on the
PDO construct that is used to refresh the class.
The error changes depending on whether a persistent connection is set or
not.
When persistent is on the above error is produced. Without persistent
connection applied the error is thrown when the class is destructed.
Example: $pdo = null;
send of 5 bytes failed with errno=32 Broken pipe
We have confirmed this to be apparent in PHP 5.3.3 and the trunk build.
I was unable to test on 5.2, but I was able to confirm this bug does not
occur on 5.1.6
I have tried wrapping ob functions around the calls in case the broken
pipe happened to be stdout but I think it is the mysql socket that is in
question. On that same note, switching mysql to connect via tcp did not
help.
From searching I found a site that threw this error but no discussions
of it.
Let me know any additional information that is needed.
Test script:
---
// without persistance
public static function shutdown(){
$base = Base::getBase();
$base-db = null;
self::$base = false;
}
// with persistance
$this-pdo = new PDO(
$dsn,
$user,
$pass,
array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT= true
)
);
Expected result:
The PDO class should startup quietly when persistent connections are
enabled and destruct quietly when persistent connections are disabled.
Actual result:
--
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
with persistent connections.
Base::shutdown(): send of 5 bytes failed with errno=32 Broken pipe
without persistent connections.
I believe this problem is only related to forked processes. I have
confirmed the standard page serving to not throw this.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53287edit=1
Bug #45900 [Com]: timelib_structs.h include path issue on Windows
Edit report at http://bugs.php.net/bug.php?id=45900edit=1 ID: 45900 Comment by: dave dot kelly at dawkco dot com Reported by:Keisial at gmail dot com Summary:timelib_structs.h include path issue on Windows Status: Bogus Type: Bug Package:Compile Failure Operating System: Windows PHP Version:5.3CVS-2008-08-23 (snap) Assigned To:pajoye Block user comment: N Private report: N New Comment: The status of this bug should not be 'Bogus' (yet anyway). I'm still getting this error with the 5.3.5 (production) source build. .../timelib_structs.h(24) : fatal error C1083: Cannot open include file: 'timelib_config.h': No such file or directory NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. It appears that the file: C:/php-sdk/php53dev/vc9/x86/php-5.3.5/ext/date/config.w32 is not executing properly during config. At the bottom of .../ext/date/config.w32 is the following: var tl_config = FSO.CreateTextFile(ext/date/lib/timelib_config.h, true); tl_config.WriteLine(#include \config.w32.h\); tl_config.Close(); If this code were executing properly during config, there wouldn't be a problem, but the timelib_config.h file is not being created for some reason. Previous Comments: [2008-09-24 22:45:36] Keisial at gmail dot com Looks it wasn't fixed as it is happening with a clean folder :( Calling configure again after the error it then builds !? php5.3-200809241430 del * /s /q cd .. tar xjf php5.3-200809241430.tar.bz2 cd php5.3-200809241430 buildconf cscript /nologo configure.js nmake snip head.c C:\PROGRA~1\Microsoft Platform SDK\Include\Ws2tcpip.h(593) : warning C4142: benign redefinition of type .\ext/date/lib/timelib_structs.h(24) : fatal error C1083: Cannot open include file: 'timelib_config.h': No such file or directory NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. nmake head.c C:\PROGRA~1\Microsoft Platform SDK\Include\Ws2tcpip.h(593) : warning C4142: benign redefinition of type .\ext/date/lib/timelib_structs.h(24) : fatal error C1083: Cannot open include file: 'timelib_config.h': No such file or directory NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. cscript /nologo configure.js nmake builds It doesn't hit the error with --disable-calendar [2008-08-25 18:55:26] paj...@php.net I have discussed with Keisal on IRC and the issue is fixed (clean co and al). [2008-08-25 18:25:53] j...@php.net Is timelib_config.h generated or not when this happens? WHERE is it generated to? Search for it, it might get generated but in a wrong directory.. [2008-08-23 21:28:33] Keisial at gmail dot com You're right. The issue is not the switch style. Why is it always documented with / ? :) The error is: .\ext/date/lib/timelib_structs.h(24) : fatal error C1083: Cannot open include file: 'timelib_config.h': No such file or directory I have gone deeper into it, and is not caused on compiling date but when compiling ext\standard\microtime.c which #include ext/date/php_date.h Interestingly, i only see it with --enable-snapshot-build and running again nmake skips it. [2008-08-23 18:00:54] paj...@php.net -I works like /I There is other extension using the -I (gd, pcre, etc.) without problems. Which error do you get (exactly)? 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/bug.php?id=45900 -- Edit this bug report at http://bugs.php.net/bug.php?id=45900edit=1
Bug #53287 [Fbk-Asn]: PDO 5 Byte write to a broken pipe when forked
Edit report at http://bugs.php.net/bug.php?id=53287edit=1
ID: 53287
User updated by:bryan dot tong at gigenet dot com
Reported by:bryan dot tong at gigenet dot com
Summary:PDO 5 Byte write to a broken pipe when forked
-Status: Feedback
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: CentOS 5.5 x86-64
PHP Version:5.3SVN-2010-11-10 (snap)
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Though it can really make parsing the output a pain when there are
multiple versions of mysqlnd floating about.
Previous Comments:
[2011-01-31 10:27:42] u...@php.net
This does not smell like an error rather more like mysqlnd being more
verbose. No bug, a feature, I'd say.
[2010-12-05 21:23:46] seza at paradoxal dot org
I have the same error message with php.5.3.3 (send of 5 bytes failed
with errno=32 Broken pipe) but in a
different context more simply to reproduce :
I have a simple website (no fork or stuff like that). It make persistent
connection with pdo to mysql
(mysqlnd). The errors are raised when the mysql is server is restarted.
When mysql server is off error message are mysql server is gone away. No
problem with that but once the
mysql server is restarted and during 15 minutes I have sometimes this
error message (send of 5 bytes
failed with errno=32 Broken pipe).
Certainly a reuse of a cached connection to mysql before it was
restarted.
PS : I use mysql_sock connection
(mysql:unix_socket=/var/run/mysqld/mysqld.sock)
[2010-11-26 13:19:45] johan...@php.net
The description mentions forking, the sample code not. Please provide a
complete script showing the issue.
[2010-11-10 03:21:00] bryan dot tong at gigenet dot com
Description:
When switching from PHP 5.1.6 to PHP 5.3.3 the following notice has
begun to show up in our scripts.
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
We are running a daemon and the forked children throw this error on the
PDO construct that is used to refresh the class.
The error changes depending on whether a persistent connection is set or
not.
When persistent is on the above error is produced. Without persistent
connection applied the error is thrown when the class is destructed.
Example: $pdo = null;
send of 5 bytes failed with errno=32 Broken pipe
We have confirmed this to be apparent in PHP 5.3.3 and the trunk build.
I was unable to test on 5.2, but I was able to confirm this bug does not
occur on 5.1.6
I have tried wrapping ob functions around the calls in case the broken
pipe happened to be stdout but I think it is the mysql socket that is in
question. On that same note, switching mysql to connect via tcp did not
help.
From searching I found a site that threw this error but no discussions
of it.
Let me know any additional information that is needed.
Test script:
---
// without persistance
public static function shutdown(){
$base = Base::getBase();
$base-db = null;
self::$base = false;
}
// with persistance
$this-pdo = new PDO(
$dsn,
$user,
$pass,
array(
PDO::ATTR_ERRMODE = PDO::ERRMODE_EXCEPTION,
PDO::ATTR_PERSISTENT= true
)
);
Expected result:
The PDO class should startup quietly when persistent connections are
enabled and destruct quietly when persistent connections are disabled.
Actual result:
--
PDO::__construct(): send of 5 bytes failed with errno=32 Broken pipe
with persistent connections.
Base::shutdown(): send of 5 bytes failed with errno=32 Broken pipe
without persistent connections.
I believe this problem is only related to forked processes. I have
confirmed the standard page serving to not throw this.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53287edit=1
Req #33604 [Asn-Dup]: MYSQL: php.ini option to set character_set and allow using UTF8
Edit report at http://bugs.php.net/bug.php?id=33604edit=1 ID: 33604 Updated by: johan...@php.net Reported by:dlacroix at erasme dot org Summary:MYSQL: php.ini option to set character_set and allow using UTF8 -Status: Assigned +Status: Duplicate Type: Feature/Change Request Package:MySQL related PHP Version:5.0.4 Assigned To:mysql Block user comment: N Private report: N New Comment: Duplicate, as ulf said. Previous Comments: [2011-01-06 17:12:00] u...@php.net Duplicate of http://bugs.php.net/bug.php?id=44118 [2010-07-25 02:02:41] mabi at gentoo dot org Just attached the patch gentoo currently ships for this. In short: it provides a mysql.connect_charset php.ini option and uses mysql_options so that each connection will have this charset set by default. We use a similar patch for mysqli. The patch is not mine (I just adapted it to work with php-5.3.3), the original credits are: Initial patch by Stuart (?) and CHTEKK Updated for 5.3 by hoffie [2005-07-07 15:43:00] dlacroix at erasme dot org Description: There is no option in php.ini to setup the character set used with the MySQL connection. I'm using PHP in UTF-8 per default, MySQL 4.1.11 in UTF-8 but when I open a connection with PHP-MySQL it use latin1. I need an option to set the character set to UTF-8 when a connection is opened like in my.cnf file for mysql client. I have written a patch for php-mysql-5.0.4. It add mysql.default_character_set variable. Like that you can set: mysql.default_character_set = utf8 I still have a problem with mysql_client_encoding function that return latin1 even if the database is well using UTF-8. But it seems to be a MySQL client problem. Without this patch PHP program like SPIP are missusing the database and thing can be double encoded in UTF-8. This patch just add the following MySQL command when a connection is opened: SET character_set_client=choosed value SET character_set_connection=choosed value SET character_set_results=choosed value Reproduce code: --- Patch is available here: http://index.erasme.org/php-5.0.4-mysql-characterset.patch else you can ask me (dlacr...@erasme.org) -- Edit this bug report at http://bugs.php.net/bug.php?id=33604edit=1
Req #44118 [Asn-Wfx]: [PATCH] MySQL: Set connection charset via php.ini option
Edit report at http://bugs.php.net/bug.php?id=44118edit=1 ID: 44118 Updated by: johan...@php.net Reported by:slava_reg at nsys dot by Summary:[PATCH] MySQL: Set connection charset via php.ini option -Status: Assigned +Status: Wont fix Type: Feature/Change Request Package:MySQL related Operating System: any PHP Version:5.2.5 Assigned To:mysql Block user comment: N Private report: N New Comment: The application has to know the encoding being used, else some strange things might happen. We have seen the trouble in having this globally configurable when Gentoo decided to use Utf-8 for their MySQL installations by default instead of MySQL's default. I doubt you can make an application Utf-8 comaptible by just setting such a low-level switch (it won't affect the HTTP Content-type header or HTML forms, thus receiving data in a wrong encoding from the user, not re-encode it etc.) Previous Comments: [2011-01-06 16:19:52] u...@php.net Not sure if this is really needed. It can be done in user land. Its a bit of a convenience feature. Not many votes for it... Andrey, Johannes...? [2008-02-14 13:00:54] slava_reg at nsys dot by Description: Hi, As I'm tired of patching various user-installed php-engines to work correctly with newer MySQL versions (4.1.x +) that require connection character set to be specified, I decided to solve the problem at the php level. So, I patched both mysql and mysqli extensions (based on an idea found somewhere in internet). Result is available at: http://bubble.nsys.by/projects/patches/php/php-5.2.5-mysql-client-charset.patch The patch introduces two more php.ini directives: mysql.client_charset and mysqli.client_charset As those directives are optional, the patch shouldn't break any existing functionality, but it could *really* help users who's native language is not latin and who want to use some php-scripted engine with mysql 'out-of-the-box'. Best, Vladislav Bogdanov -- Edit this bug report at http://bugs.php.net/bug.php?id=44118edit=1
Bug #51336 [Opn-Csd]: snmprealwalk (snmp v1) does not handle end of OID tree correctly
Edit report at http://bugs.php.net/bug.php?id=51336edit=1
ID: 51336
Updated by: lytbo...@php.net
Reported by:lytboris at gmail dot com
Summary:snmprealwalk (snmp v1) does not handle end of OID
tree correctly
-Status: Open
+Status: Closed
Type: Bug
Package:SNMP related
Operating System: *
PHP Version:Irrelevant
-Assigned To:
+Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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:
[2011-01-31 12:34:14] lytbo...@php.net
Automatic comment from SVN on behalf of lytboris
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307876
Log: Fixed bug #51336
[2010-12-01 20:56:30] lytboris at gmail dot com
Any progress on this bug?
[2010-03-20 11:52:24] lytboris at gmail dot com
Description:
When snmprealwalk is asked for complete OID tree (thus it may not be .
OID but every OID prefix covers system-wide last OID) it does not handle
nosuchname error (that is used in snmpv1 as NOSUCHINSTANCE) reported by
agent correctly showing nonsense warnings.
This is because error handling case does not `know' about
SNMP_CMD_REALWALK query type, only about SNMP_CMD_WALK.
Test script:
---
?php
$machine_ip = 127.0.0.1;
$community = public;
$oid= .1.3.6.1;
#$oid= .1.3.6.1.2.1.1;
snmp_set_oid_output_format(SNMP_OID_OUTPUT_NUMERIC);
$walk_result = snmprealwalk($machine_ip, $community, $oid);
if (empty($walk_result)) {
print It's busted\n;
exit(0);
} else {
print Number of entries: . count($walk_result) . \n;
}
?
Expected result:
Number of entries: about 4k
Actual result:
--
PHP Warning: snmprealwalk(): Error in packet: (noSuchName) There is no
such variable name in this MIB. in
/home/nc/tmp/perl-snmp-test-case/case-1/php-walk-case1.php on line 8
PHP Warning: snmprealwalk(): This name does not exist:
iso.3.6.1.6.3.16.1.5.2.1.6.6.115.121.115.116.101.109.1.1 in
/home/nc/tmp/perl-snmp-test-case/case-1/php-walk-case1.php on line 8
It's busted
--
Edit this bug report at http://bugs.php.net/bug.php?id=51336edit=1
Bug #44287 [Asn-Wfx]: mysql_fetch_object calls __construct too late
Edit report at http://bugs.php.net/bug.php?id=44287edit=1 ID: 44287 Updated by: johan...@php.net Reported by:jaap dot taal at gmail dot com Summary:mysql_fetch_object calls __construct too late -Status: Assigned +Status: Wont fix Type: Bug Package:MySQL related Operating System: * PHP Version:Any Assigned To:mysql Block user comment: N Private report: N New Comment: The mysql extension isn't extended we certainly shouldn't break the compatibility in this extension in any way. New applications should use mysqli or PDO_mysql ... Previous Comments: [2011-01-16 01:10:12] ka...@php.net I think we should fix this behaviour in trunk and make a note about the change in the upgrading files so its highlighted in the manual once released. [2011-01-05 17:28:32] u...@php.net Any version affected. Its questionable if we should change this and break BC. [2010-11-02 17:32:10] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-11-10 01:00:06] 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. [2008-11-02 13:35:01] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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/bug.php?id=44287 -- Edit this bug report at http://bugs.php.net/bug.php?id=44287edit=1
Bug #45893 [Opn-Csd]: Snmp buffer limited to 2048 char
Edit report at http://bugs.php.net/bug.php?id=45893edit=1 ID: 45893 Updated by: lytbo...@php.net Reported by:nept_uno at hotmail dot com Summary:Snmp buffer limited to 2048 char -Status: Open +Status: Closed Type: Bug Package:SNMP related Operating System: * PHP Version:5.*, 6CVS (2009-01-21) -Assigned To: +Assigned To:lytboris Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. 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. As a part of FR#53594 Previous Comments: [2008-08-22 14:24:54] nept_uno at hotmail dot com Description: snmpget return string with max size 2048 char. If a mib variable contains more than 2048 char, string result isn't complete. I think that problem occurs because in file ext/snmp/snmp.c there is this declaration: char buf[2048]; I'm trying to extend this size (i.e. 4096) but I don't know if this is the solution. Reproduce code: --- $result = @snmpget($ip, $community, $OID_MIB, $timeout, $retries); Expected result: Hex-STRING: 00 01 00 03 03 F3 03 FD 03 FE 04 07 04 11 04 25 04 2F 04 30 04 39 04 3A 04 43 04 4D 04 57 04 58 04 6B 04 6C 04 75 04 76 04 7F 04 93 04 9D 04 A7 04 A8 04 B1 04 BB 04 BC 04 C5 04 CF 04 D9 04 E3 04 ED 04 F7 04 F8 05 01 05 0B 05 0C 05 15 05 1F 05 29 05 33 05 34 05 3D 05 3E 05 47 05 48 05 51 05 5B 05 65 05 6F 05 79 05 83 05 8D 05 8E 05 A1 05 AB 05 B5 05 B6 05 C9 05 CA 07 E5 07 E6 07 EF 07 F9 08 03 08 0D 08 17 08 2B 08 35 08 3F 08 40 08 49 08 4A 08 53 08 67 08 71 08 7B 08 85 08 99 08 A3 08 A4 08 AD 08 B7 08 B8 08 C1 08 CB 08 D5 08 D6 08 DF 08 E9 08 EA 08 F3 08 FD 09 07 09 1B 09 1C 09 25 09 2F 09 30 09 39 09 3A 09 43 09 4D 09 61 09 6B 09 75 09 7F 09 80 09 89 09 93 09 9D 09 A7 09 B1 09 B2 0B C3 0B CD 0B CE 0B D7 0B D8 0B E1 0B EB 0B F5 0B FF 0C 00 0C 0A 0C 13 0C 14 0C 1D 0C 1E 0C 27 0C 31 0C 3B 0C 45 0C 4F 0C 59 0C 63 0C 6D 0C 77 0C 81 0C 82 0C 8B 0C 95 0C 9F 0C A9 0C B3 0C BD 0C C7 0C D1 0C DB 0C DC 0C E5 0C EF 0C F9 0D 03 0D 0D 0D 17 0D 21 0D 2B 0D 35 0D 3F 0D 49 0D 53 0D 5D 0D 67 0D 71 0D 7B 0D 85 0D 8F 0D 90 0D 99 0F AB 0F B5 0F BF 0F C9 0F DD 0F E7 0F F1 0F F2 0F FB 10 05 10 06 10 0F 10 23 10 2D 10 37 10 41 10 4B 10 55 10 56 10 5F 10 69 10 73 10 74 10 7D 10 87 10 91 10 92 10 9B 10 A5 10 AF 10 B0 10 B9 10 BA 10 C3 10 C4 10 CD 10 CE 10 D7 10 E1 10 E2 10 EB 10 EC 10 F5 10 FF 11 09 11 13 11 1D 11 27 11 31 11 3B 11 45 11 4F 11 59 11 63 11 6D 11 77 11 81 11 82 13 9D 13 9E 13 A7 13 B1 13 BB 13 BC 13 C5 13 CF 13 D9 13 E3 13 E4 13 ED 13 F7 13 F8 14 01 14 02 14 0B 14 0C 14 15 14 16 14 1F 14 29 14 33 14 3D 14 3E 14 47 14 5B 14 65 14 6F 14 79 14 7A 14 83 14 97 14 98 14 A1 14 AB 14 B5 14 B6 14 BF 14 C9 14 CA 14 D3 14 E7 14 F1 14 FB 15 05 15 06 15 0F 15 19 15 23 15 24 15 2D 15 37 15 41 15 4B 15 4C 15 55 15 56 15 5F 17 7B 17 85 17 8F 17 99 17 A3 17 A4 17 AD 17 AE 17 B7 17 C1 17 CB 17 D5 17 D6 17 DF 17 E0 17 E9 17 F3 17 FD 17 FE 18 07 18 11 18 1B 18 1C 18 25 18 2F 18 30 18 39 18 3A 18 43 18 4D 18 57 18 61 18 62 18 75 18 7F 18 89 18 93 18 9D 18 9E 18 A7 18 B1 18 BB 18 C5 18 CF 18 D9 18 E3 18 ED 18 EE 18 F7 19 01 19 0B 19 0C 19 15 19 16 19 1F 19 20 19 29 19 33 19 3D 19 3E 19 47 19 48 19 51 1B 63 1B 6D 1B 77 1B 81 1B 8B 1B 8C 1B 95 1B 96 1B 9F 1B A9 1B B3 1B B4 1B BD 1B BE 1B C7 1B C8 1B D1 1B D2 1B DB 1B E5 1B EF 1B F9 1B FA 1C 03 1C 0D 1C 17 1C 18 1C 2B 1C 35 1C 3F 1C 40 1C 53 1C 5D 1C 5E 1C 67 1C 71 1C 7B 1C 7C 1C 85 1C 8F 1C 99 1C A3 1C A4 1C AD 1C AE 1C B7 1C C1 1C CB 1C D5 1C DF 1C E0 1C E9 1C F3 1C F4 1C FD 1D 07 1D 25 1D 2F 1D 39 1F 4B 1F 56 1F 60 1F 6A 1F 74 1F 7E 1F 92 1F 93 1F 9C 1F A6 1F B0 1F C4 1F C5 1F CE 1F D8 1F EC 1F F6 1F F7 20 00 20 01 20 0A 20 14 20 1E 20 1F 20 28 20 29 20 32 20 33 20 3C 20 3D 20 46 20 50 20 51 20 5A 20 64 20 65 20 6E 20 78 20 82 20 83 20 8C 20 96 20 97 20 A0 20 AA 20 B4 20 B5 20 BE 20 BF 20 C8 20 D2 20 D3 20 DC 20 DD 20 E6 20 F0 20 F1 20 FA 21 04 21 0E 21 18 21 19 21 22 21 23 27 1B 27 1C 27 25 27 26 27 2F 27 30 27 39 27 3A 27 43 27 44 27 4D 27 57 27 61 27 6B 27 75 27 7F 27 80 27 89 27 93 27 9D 27 9E 27 A7 27 A8 27 B1 27 B2 27 BB 27 BC 27 C5 27 C6 27 CF 27 D9 27 E3 27 ED 27 F7 28 01 28 0B 28 0C 28 15 28 16 28 1F 28 20 28 29 28 33 28 3D 28 47 28 48 28 51 28 5B 28 65 28 66 28 6F 28 70 28 79 28 83 28 8D 28 97 28 98 28 A1 28 AB 28 AC 28 B5 28 B6 28 BF 28 C9 28 D3 28 D4 28 DD 28 E7 28 F1 28 F2 2B 03 2B 17 2B 18 2B 21 2B 22 2B 2B 2B 2C 2B 35 2B 36 2B 3F 2B 40 2B 49 2B 53 2B 5D 2B 67 2B 71 2B 7B 2B 85 2B 8F 2B 99 2B A3 2B AD 2B B7 2B C1 2B CB 2B D5 2B DF 2B
Bug #53862 [Opn-Fbk]: snmp_set_oid_output_format does not allow returning to default etc
Edit report at http://bugs.php.net/bug.php?id=53862edit=1
ID: 53862
Updated by: lytbo...@php.net
Reported by:mloftis at wgops dot com
Summary:snmp_set_oid_output_format does not allow returning
to default etc
-Status: Open
+Status: Feedback
Type: Bug
Package:SNMP related
Operating System: Irrelevant
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please check OO API from trunk. It has an option to specify session-wise
OID output format and more.
Sources in trunk can be compiled against downto php 5.2
Previous Comments:
[2011-01-28 00:18:00] mloftis at wgops dot com
Description:
snmp_set_oid_output_format only allows using the FULL
(SNMP_OID_OUTPUT_FULL) or
NUMERIC (SNMP_OID_OUTPUT_NUMERIC) setting types, neither of which is the
default.
It also has no corresponding _get_ function call to query/store and
return the
setting back to whatever it was before I touched it
I've attached a patch which does both (from the 5.3 branch), extends the
existing
function to include the available types in UCD Net-SNMP as of 5.4 (not
verified/checked against older ones, have not verified that setting to
_NONE will
not cause crashes).
Test script:
---
$rvDefault = snmp2_get('127.0.0.1','public','.1.3.6.1.2.1.1.2.0');
snmp_set_oid_output_format(SNMP_OID_OUTPUT_FULL);
$rvFull = snmp2_get('127.0.0.1','public','.1.3.6.1.2.1.1.2.0');
snmp_set_oid_output_format(SNMP_OID_OUTPUT_NUMERIC);
$rvNumeric = snmp2_get('127.0.0.1','public','.1.3.6.1.2.1.1.2.0');
echo $rvDefault.\n;
echo $rvFull.\n;
echo $rvNumeric.\n;
Expected result:
Setting either SNMP_OID_OUTPUT_FULL or SNMP_OID_OUTPUT_NUMERIC would
return the
library to it's default. Expect there to be an
snmp_get_oid_output_format call as
well to query the current setting.
Actual result:
--
Neither of the available snmp_set_oid_output_format constants can return
the
library to it's default settings. No ability to query the library for
the current
setting.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53862edit=1
Req #53594 [Fbk-Tbd]: php-snmp rewrite
Edit report at http://bugs.php.net/bug.php?id=53594edit=1 ID: 53594 Updated by: lytbo...@php.net Reported by:lytboris at gmail dot com Summary:php-snmp rewrite -Status: Feedback +Status: To be documented Type: Feature/Change Request Package:SNMP related Operating System: irrelevant PHP Version:trunk -Assigned To: +Assigned To:lytboris Block user comment: N Private report: N New Comment: OO API should be documented from scratch as most of old API functions Previous Comments: [2011-01-31 12:41:36] lytbo...@php.net Automatic comment from SVN on behalf of lytboris Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307877 Log: Improved SNMP extension. FR #53594 [2011-01-05 19:04:56] lytboris at gmail dot com Introducing full-featured OO API. It covers bug #46065 also. Old API *_set_* functions actually sets `global' preferences, they are used when creating new object instance. $object-... properties are used object(session)-wise. [2010-12-31 19:52:07] lytboris at gmail dot com OK. There will be full-featured OO API without adding new functions into legacy API (e.g. no session support). Though old functions will be provided with two features (in sake of code cimplicity): * multi-OID * strict output typing [2010-12-29 18:22:55] paj...@php.net No need to deprecate it, but tell anyone asking for a feature for the legacy API to migrate to the new shiny one :) [2010-12-29 18:21:57] paj...@php.net It is much easier and cleaner to simply go straight to OO then, without procedural API, and keep the old for legacy apps. 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/bug.php?id=53594 -- Edit this bug report at http://bugs.php.net/bug.php?id=53594edit=1
Bug #46065 [Opn-Fbk]: snmp_set_quick_print() persists between requests
Edit report at http://bugs.php.net/bug.php?id=46065edit=1 ID: 46065 Updated by: lytbo...@php.net Reported by:php at painfullscratch dot nl Summary:snmp_set_quick_print() persists between requests -Status: Open +Status: Feedback Type: Bug Package:SNMP related Operating System: * PHP Version:5.*, 6 -Assigned To: +Assigned To:lytboris Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php-trunk-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Please check OO API from trunk. It has an option to specify session-wise OID output format and more. Sources in trunk can be compiled against downto php 5.2 Previous Comments: [2009-09-08 21:16:19] larryjadams at comcast dot net The snmp module needs a bit of rededesign. It should handle many of the commands from the native calls, like multiple OID get's in a single array, in other words, make the OID a mixed type for a get request. Also, the snmp functions should require a resource (aka snmp session) in order to work, just like is done in the API, for which it would be based. In that case, to setup a quick print, you start a session, receive a pointer to a (structure/resource) in return and then all subsequent calls need to also pass the resource to the function. Once you are done, you need to close the sessions. This will have to be a new class of calls though as simply changing thing around will make life difficult for everyone. TheWitness [2008-10-24 08:56:21] j...@php.net It's pretty simple issue, propably need to add some netsnmp shutdown function in RINIT which clears all the settings between requests. [2008-09-12 13:27:09] php at painfullscratch dot nl Description: When PHP runs under Apache and snmp_set_quick_print(TRUE) is issued, the behavior of all SNMP-related functions will be quick print for the lifetime of the PID. NET-SNMP Support = enabled NET-SNMP Version = 5.4.1 PHP version: 5.2.4 There are two possibilities: 1) This behavior is by design: If this is the case I think the manual page for snmp_set_quick_print() needs a warning for this behavior. 2) This is a bug: For each PID the behavior should be (re)set to the default behavior after execution of the script. Reproduce code: --- pet@workmate:/tmp$ sudo /etc/init.d/apache2 restart /dev/null 21 pet@workmate:/tmp$ for (( i=0; i5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9402' snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '' | pid: '9406' pet@workmate:/tmp$ links -dump http://localhost/snmp_set_quick_print.php snmp_set_quick_print: '' | pid: '9406' pet@workmate:/tmp$ for (( i=0; i5; i++ )) ; do links -dump http://localhost/snmp_get_quick_print.php; done snmp_get_quick_print: '' | pid: '9403' snmp_get_quick_print: '' | pid: '9404' snmp_get_quick_print: '' | pid: '9446' snmp_get_quick_print: '' | pid: '9405' snmp_get_quick_print: '1' | pid: '9406' -- Edit this bug report at http://bugs.php.net/bug.php?id=46065edit=1
Req #45395 [Opn-Wfx]: snmpgetnext only returns value
Edit report at http://bugs.php.net/bug.php?id=45395edit=1 ID: 45395 Updated by: lytbo...@php.net Reported by:chrisohaver at gmail dot com Summary:snmpgetnext only returns value -Status: Open +Status: Wont fix Type: Feature/Change Request Package:SNMP related Operating System: Linux PHP Version:5.2.6 -Assigned To: +Assigned To:lytboris Block user comment: N Private report: N New Comment: Value-only is the desired result. If you need to get OID with it's value simultaneously you may try new OO API available in trunk: $session-getnext(array($oid)) will return an associative array oid = value. Previous Comments: [2008-06-30 20:17:30] chrisohaver at gmail dot com Description: snmpgetnext does not return the value and oid of the next object. Reproduce code: --- $snmp_response = snmpgetnext($hostname, $community, $object_id); Expected result: snmpgetnext should return the value and the oid of the next object. Actual result: -- snmpgetnext only returns the value of the next object. The next oid is not returned. -- Edit this bug report at http://bugs.php.net/bug.php?id=45395edit=1
Bug #44193 [Opn-Fbk]: snmp v3 noAuthNoPriv doesn't work
Edit report at http://bugs.php.net/bug.php?id=44193edit=1
ID: 44193
Updated by: lytbo...@php.net
Reported by:mavezeau at colubris dot com
Summary:snmp v3 noAuthNoPriv doesn't work
-Status: Open
+Status: Feedback
Type: Bug
Package:SNMP related
Operating System: Mandriva 2005/linux
PHP Version:5.2CVS-2008-10-27
-Assigned To:
+Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
Please try using this snapshot:
http://snaps.php.net/php-trunk-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
There is full support for SNMPv3 (with contextName and EngineID) in OO
API available in trunk. It needs to be documented though.
Previous Comments:
[2009-09-08 21:21:55] larryjadams at comcast dot net
That's not quite it. That section of the code simply needs to be
finished, let alone be documented.
[2008-10-27 16:33:50] mavezeau at colubris dot com
Now,
Some parts work. The security level AuthNoPriv and AuthPriv work but
noAuthNoPriv doesn't works because php doesn't accept null or '' to
auth_protocol and priv_protocol. I think this fix is simple the snmp v3
with noAuthNopriv is very similar of snmp v2c.
if I try:
snmp3_walk('192.168.130.124','test','noAuthNoPriv','MD5','','','','');
I have this error error(snmp3_walk(): Could not generate key for
authentication pass phrase: MD5)
if I try:
snmp3_walk('192.168.130.124','test','noAuthNoPriv',null,null,null,null,'');
or
snmp3_walk('192.168.130.124','test','noAuthNoPriv','',null,null,null,'');
I have this error Invalid authenfication protocol:
[2008-02-20 21:23:28] mavezeau at colubris dot com
Description:
I try to make a query with snmp v3 and I have an error: snmp3_walk():
An error occurred or snmp3_walk(): No response from 192.168.130.124.
If I execute a query with net-snmp 5.4.1 the query is ok. If I execute
the similar query with php I have those errors.
Reproduce code:
---
AuthNoPriv
net-snmp Query:
snmpwalk -v 3 -l authNoPriv -a MD5 -A jesuisuntest -u test5
192.168.130.124
it Works!
Php snmp
snmp3_walk('192.168.130.124','test5','authNoPriv','MD5','jesuisuntest','','','');
Error !
noAuthNoPriv
net-snmp query:
snmpwalk -v 3 -l noAuthNoPriv -u test 192.168.130.124
it works!
PHP snmp
snmp3_walk('192.168.130.124','test','noAuthNoPriv','','','','','');
error(snmp3_walk(): Invalid authentication protocol)
if use the default
snmp3_walk('192.168.130.124','test','noAuthNoPriv','MD5','','','','');
error(snmp3_walk(): Could not generate key for authentication pass
phrase: MD5)
Expected result:
Similar return value than smnp v2c
Actual result:
--
all method make an error
--
Edit this bug report at http://bugs.php.net/bug.php?id=44193edit=1
Req #34910 [Opn-Bgs]: OID not parsed with invalid string index
Edit report at http://bugs.php.net/bug.php?id=34910edit=1
ID: 34910
Updated by: lytbo...@php.net
Reported by:ch at westend dot com
Summary:OID not parsed with invalid string index
-Status: Open
+Status: Bogus
Type: Feature/Change Request
Package:SNMP related
Operating System: Debian GNU/Linux
PHP Version:5CVS-2005-11-02 (snap)
-Assigned To:
+Assigned To:lytboris
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.
Previous Comments:
[2005-11-02 13:59:56] ch at westend dot com
What about beeing a bit more polite, eh?
I tried the latest snapshot and the problem apparently has not been
fixed in the meantime or you have to tell me where my syntax is wrong.
$ snmpget -v 1 -Ir -c stinger-test
'ASCEND-MIBINET-MIB::internetProfile-Station.cir-1-9'
ASCEND-MIBINET-MIB::internetProfile-Station.cir-1-9 = STRING:
cir-1-9
$ cat t.php
?php
print snmpget(stinger-test.westend.com, X,
'ASCEND-MIBINET-MIB::internetProfile-Station.cir-1-9').\n;
?
ch@xeniac:/tmp/php5-200511020730$ ./sapi/cli/php ~ch/t.php
Warning: snmpget(): Invalid object identifier:
ASCEND-MIBINET-MIB::internetProfile-Station.cir-1-9 in /home/ch/t.php
on line 4
bye,
-christian-
[2005-10-18 18:22:45] ch at westend dot com
Description:
The SNMP function seem to not know that it is possible
to have string indices like:
$ snmpwalk -Ir myhost \
'ASCEND-MIBINET-MIB::internetProfile-Active.cir-1-26'
which gives:
ASCEND-MIBINET-MIB::internetProfile-Active.cir-1-26 =
INTEGER: yes(2)
(keep the single and double quotes in the example!)
It seems that setting the -Ir flag is not possible.
Reproduce code:
---
$x = snmprealwalk('myhost', 'mypassword',
ASCEND-MIBINET-MIB::internetProfile-Station);
var_export($x); print(\n);
gives:
array (
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-2' = 'STRING:
bras-1-2',
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-3' = 'STRING:
bras-1-3',
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-4' = 'STRING:
bras-1-4',
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-48' = 'STRING:
bras-1-48',
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-5' = 'STRING:
bras-1-5',
'ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-6' = 'STRING:
bras-1-6',
Numerically this OID looks like:
$ snmpwalk -Ir -On myhost \
'ASCEND-MIBINET-MIB::internetProfile-Active.cir-1-26'
.1.3.6.1.4.1.529.23.1.1.1.2.8.99.105.114.45.49.45.50.54 = INTEGER:
yes(2)
The MIB definition looks like this:
mibinternetProfileTable OBJECT-TYPE
SYNTAX SEQUENCE OF MibinternetProfileEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION A list of mibinternetProfile profile entries.
::= { mibinternetProfile 1 }
mibinternetProfileEntry OBJECT-TYPE
SYNTAX MibinternetProfileEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION A mibinternetProfile entry containing objects
that
maps to the parameters of mibinternetProfile
profile.
INDEX { internetProfile-Station }
::= { mibinternetProfileTable 1 }
MibinternetProfileEntry ::=
SEQUENCE {
internetProfile-Station
DisplayString,
internetProfile-Active
INTEGER,
internetProfile-Active OBJECT-TYPE
SYNTAX INTEGER {
no (1),
yes (2)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION A profile can be disabled by setting this field
to no. There is no difference between an inactive pr
::= { mibinternetProfileEntry 2 }
Expected result:
I would have expected to be able to use every OID that the
above snmpwalk returns. But they are claimed to be invalid.
Actual result:
--
Warning: snmpget(): Invalid object identifier:
ASCEND-MIBINET-MIB::internetProfile-Station.bras-1-2 in /home/ch/t.php
on line 10
--
Edit this bug
Req #27967 [Ana-Bgs]: SNMP: need function to load additional MIBs
Edit report at http://bugs.php.net/bug.php?id=27967edit=1 ID: 27967 Updated by: lytbo...@php.net Reported by:mac dot and dot cheese at hush dot com Summary:SNMP: need function to load additional MIBs -Status: Analyzed +Status: Bogus Type: Feature/Change Request Package:SNMP related Operating System: win32 only PHP Version:4.3.4 -Assigned To: +Assigned To:lytboris Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. Previous Comments: [2004-04-28 09:48:52] har...@php.net 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. Thank you for your interest in PHP. Hi, A default installation of NET-SNMP does not include the HOST-RESOURCES-MIB in MIB modules read at start up time. IIRC, due to this MIB module is not fully supported on the Windows platform (for the agent side). You need to have the HOST_RESOURCES-MIB, someone else will need another MIB, and maybe some one will need a enterprise specific MIB module. It will become impossible to fulfil all those requests and people depending on other MIB modules better built the binary themselves. (note, I do not built the binary version, so he may choose differently) Of course, an option is to add a configuration function with which additional MIB modules can be loaded in PHP. [2004-04-12 17:40:28] mac dot and dot cheese at hush dot com Description: Working with Windows PHP 4.3.4 or 4.3.5 SNMP does not load all MIBS in c:/usr/mibs directory. php_snmp.dll compiled without HOST-RESOURCES_MIB. Suggest adding additional MIBs to DEFAULT-MIB string in php_snmp.dll. I used a Hex Editor and modified the MIB String in the dll, adding HOST-RESOURCES.MIB;; (replacing SNMP-NOTIFICATION_MIB) and got desired results from snmprealwalk command. Add additional MIBs matching those provided with PHP release. Could not fine another reference to loading additional MIBs NOTE: Unix (FreeBSD 4.9 - PHP 4.3.4) returns all of the text descriptors correctly. ucd-snmp 4.2.3 DEFAULT-MIBS (config.h) included HOST-RESOURCES-MIB and others... Reproduce code: --- snmprealwalk(127.0.0.1,public,); snmpwalk or snmpwalkoid performs the same Expected result: host.hrSystem.hrSystemUptime.0 | Timeticks: (161078621) 18 days, 15:26:26.21 Actual result: -- 25.1.1.0 | Timeticks: (161078621) 18 days, 15:26:26.21 -- Edit this bug report at http://bugs.php.net/bug.php?id=27967edit=1
Bug #53795 [Asn-Csd]: Connect Error from MySqli (mysqlnd) when using SSL
Edit report at http://bugs.php.net/bug.php?id=53795edit=1
ID: 53795
Updated by: ka...@php.net
Reported by:dave dot kelly at dawkco dot com
Summary:Connect Error from MySqli (mysqlnd) when using SSL
-Status: Assigned
+Status: Closed
Type: Bug
Package:MySQLi related
Operating System: Windows
PHP Version:5.3.5
Assigned To:kalle
Block user comment: N
Private report: N
New Comment:
This bug has been fixed in SVN.
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:
[2011-01-31 13:47:31] ka...@php.net
Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=307880
Log: Fixed bug #53795 (Connect Error from MySqli (mysqlnd) when using
SSL)
[2011-01-30 11:35:52] ka...@php.net
I got an idea why this fails, as MYSQLND_SSL_SUPPORTED is not defined on
Windows, its a simple one line fix that I will commit shortly
[2011-01-29 09:36:07] dave dot kelly at dawkco dot com
FYI (you probably already know): there are currently no SSL/TLS options
available to be set with the mysqli::options method.
I tried using the mysqli::ssl_set method as follows, but it didn't work
either (same connect error):
$mysqli-ssl_set(NULL, // key file path or NULL
NULL, // cert file path or NULL
'C:/ssl/ca-cert.pem', // ca cert file path or NULL
NULL, // capath directory or NULL
'DHE-RSA-AES256-SHA'); // cipher or NULL
Also, tried the following (no luck):
$mysqli-ssl_set('C:/ssl/key.pem', // key file path or NULL
'C:/ssl/cert.pem', // cert file path or NULL
'C:/ssl/ca-cert.pem', // ca cert file path or NULL
NULL, // capath directory or NULL
NULL); // cipher or NULL
As noted before, these all work with PHP 5.2.17, but not with PHP
5.3.5.
A fix for mysqlnd would be great because trying to do a custom build on
Windows with mysqlnd disabled has become a real ordeal.
[2011-01-24 11:12:59] and...@php.net
No, mysqlnd doesn't use my.ini/my.cnf files, as libmysql did. You have
to set your options manually.
[2011-01-24 10:21:41] u...@php.net
mysqlnd does not read default files, AFAIK. I think Andrey wants to
deprecate that, Andrey?
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/bug.php?id=53795
--
Edit this bug report at http://bugs.php.net/bug.php?id=53795edit=1
[PHP-BUG] Bug #53891 [NEW]: iconv_mime_encode() fails converting UTF-8 string to quoted-printable
From:
Operating system: GNU/linux (gentoo/kernel 2.6.35)
PHP version: 5.3.5
Package: Mail related
Bug Type: Bug
Bug description:iconv_mime_encode() fails converting UTF-8 string to
quoted-printable
Description:
iconv_mime_encode() fails on certain UTF-8 strings containing at least one
multibyte character. The error is reproducable for these strings.
I have further noticed that it is more likely that this error occurs if a
multibyte character is found at the following character positions within
the string:
24±1, 52±3, 82±4, 112±5, 143±5
The code that led me to the previous conclusion can be found here:
http://pastebin.com/GXQZ129M
Test script:
---
$preferences = array(
'scheme' = 'Q',
'input-charset' = 'utf-8',
'output-charset' = 'utf-8',
'line-length' = 74,
'line-break-chars' = \r\n,
);
// Note the ellipsis character at the end of the following string:
iconv_mime_encode('subject', d obeybiubrsfqllpdtpgeâ¦, $preferences);
Actual result:
--
PHP Notice: iconv_mime_encode(): Unknown error (7) in
/home/soulmerge/test.php on line 11
Notice: iconv_mime_encode(): Unknown error (7) in /home/soulmerge/test.php
on line 11
--
Edit bug report at http://bugs.php.net/bug.php?id=53891edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53891r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53891r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53891r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53891r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53891r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53891r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53891r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53891r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53891r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53891r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53891r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53891r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53891r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53891r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53891r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53891r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53891r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53891r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53891r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53891r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53891r=mysqlcfg
Bug #53854 [Asn]: Missing constants for compression type.
Edit report at http://bugs.php.net/bug.php?id=53854edit=1
ID: 53854
Updated by: rquadl...@php.net
Reported by:rquadl...@php.net
Summary:Missing constants for compression type.
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: n/a
PHP Version:5.3SVN-2011-01-27 (SVN)
Assigned To:aharvey
Block user comment: N
Private report: N
New Comment:
I've built a zip file containing the following compression methods (the
table below shows the value, the constant name and
ZipArchive::getStatusString()'s output when decompression is attempted
and fails) :
0 : CM_STORE : Decompression supported.
1 : CM_SHRINK : Compression method not supported.
6 : CM_IMPLODE: Compression method not supported.
8 : CM_DEFLATE: Decompression supported.
9 : CM_DEFLATE64 : Compression method not supported.
10 : CM_PKWARE_IMPLODE : Compression method not supported.
12 : CM_BZIP2 : Compression method not supported.
14 : CM_LZMA : Compression method not supported.
97 : CM_WAVPACK: Compression method not supported.
98 : CM_PPMD : Compression method not supported.
I cannot find any app that will create a ZIP file using the following
compression methods.
2 : CM_REDUCE_1
3 : CM_REDUCE_2
4 : CM_REDUCE_3
5 : CM_REDUCE_4
18 : CM_TERSE
19 : CM_LZ77
I have Terse (Hercules app) and LZ77 (I think this is the Microsoft
Compress format), but they do not create .ZIP files and the files
magic-bytes are not zip related - so you can't just call the file a .zip
file and get away with it.
I've got nowhere with REDUCE.
I've got a zip file and .phpt test to cover the compression methods I
have found.
Given what I've found so far, I'm guessing that php_zip only really
supports storing and deflating/inflating. The constants for the
compression methods that I've managed to test should be exposed.
Those that I've not should be removed be unexposed and removed from the
documentation.
But I'd like to add to the docs something along the lines of Other
compression methods may exist.
Richard.
Previous Comments:
[2011-01-28 12:27:04] paj...@php.net
Let try to keep this discussion sane...:
We can keep them only if it is supported at least to read the
information about
an entry. For example, if an entry uses LZ77, then doing a stat/reading
the info
MUST return CW_LZ77.
If that's not the case, then we must remove them as it makes no sense to
expose
them to the user.
Is it more clear now? :)
[2011-01-28 12:11:02] rquadl...@php.net
Just as an aside, the error constants that ARE documented ... I can see
no way to
generate them. None of the methods or functions in php_zip return an
error
constant. Should these be removed?
[2011-01-28 12:06:05] paj...@php.net
That's what I asked. We can keep them only and only if libzip detects
AND uses
these compression types correctly. It seems to be the case. Can you
confirm it and
maybe add a test per compression method?
[2011-01-28 12:03:35] rquadl...@php.net
I took a file (an uncompressed WAV file) and compressed it using WinZip
V15 using different algorithms.
Using the following code ...
?php
$zip = new ZipArchive;
$zip-open('wav.zipx');
foreach(range(0, $zip-numFiles - 1) as $index) {
print_r($stat = $zip-statIndex($index));
$zip-extractTo('.', array($stat['name']));
echo $zip-getStatusString(), PHP_EOL;
}
$zip-close();
Outputs ...
Array
(
[name] = WavPack.wav
[index] = 0
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 45366
[comp_method] = 97
)
Compression method not supported
Array
(
[name] = PPMD.wav
[index] = 1
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 100729
[comp_method] = 98
)
Compression method not supported
Array
(
[name] = LZMA.wav
[index] = 2
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 68162
[comp_method] = 14
)
Compression method not supported
Array
(
[name] = BZIP2.wav
[index] = 3
[crc] = 1384274557
[size] = 154826
[mtime] = 1296208410
[comp_size] = 104633
[comp_method] = 12
)
Compression method not supported
As you can see, 98, 97, 14 and 12 are all identified as the comp_method
(correctly). None of these compression methods are supported by php_zip,
but the constants should be present to allow determination of the method
used.
Interestingly WavPack was the best algorithm
Bug #53850 [Opn]: openssl_pkey_export() with password not protecting private key
Edit report at http://bugs.php.net/bug.php?id=53850edit=1
ID: 53850
User updated by:jason dot gerfen at gmail dot com
Reported by:jason dot gerfen at gmail dot com
Summary:openssl_pkey_export() with password not protecting
private key
Status: Open
Type: Bug
Package:OpenSSL related
Operating System: arch linux x86_64
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Since I have not heard anything else about this I did some digging to
try and identify the problem.
I have been adding some warning output in the
'openssl-1.0.0c/crypto/pem/pem_pkey.c' file after reviewing the the
'php-5.3.5/ext/openssl/openssl.c' file and noticing and focusing on the
calls to the OpenSSL shared objects for 'PEM_write_bio_PrivateKey()'.
When adding the warning output flags in the
'OpenSSL-1.0.0c/crypt/pem/pem_pkey.c' the password argument would always
display as '(null)'.
Correct me if I am looking the wrong spot in helping identify the
problem.
Previous Comments:
[2011-01-28 19:42:32] jason dot gerfen at gmail dot com
I have verified this under the following conditions.
Arch Linux x86_64 installation
This configuration returns a password protected private key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-0.9.8q
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-0.9.8q]
This configuration however does not return a password protected key
Apache 2.2 [./configure]
OpenSSL 0.9.8q [./config --openssldir=/usr/local/openssl-1.0.0c
--shared]
PHP 5.3.5 [./configure --with-apxs2=/usr/local/apache2/bin/apxs
--disable-cli --with-openssl=/usr/local/openssl-1.0.0c]
Anything else you might find pertinent?
[2011-01-26 20:12:04] paj...@php.net
There is no different code in php to deal with this function.
If two versions of openssl give you two different results then it is a
openssl
problem, not php.
Also I would like you to test using the same PHP versions vs two
openssl, then we
can begin to discuss a possible issue. Be sure to use the latest
versions
available at php.net, not the centos (or any other distro) you use.
[2011-01-26 20:04:50] jason dot gerfen at gmail dot com
Description:
I have tested this against php5.3.5 with OpenSSL 1.0.0c (arch linux) vs
an older server running php5.2.14 with OpenSSL 0.9.8e (centos linux).
Test script:
---
$opts = array('config'='openssl.cnf',
'encrypt_key'=true,
'private_key_type'=OPENSSL_KEYTYPE_RSA,
'digest_alg'='sha256',
'private_key_bits'=2048,
'x509_extensions'='usr_cert');
$handle = openssl_pkey_new($opts);
openssl_pkey_export($handle, $privatekey, sha1($_SERVER['REMOTE_ADDR']),
$opts);
echo $privatekey;
Expected result:
CentOS example output
-BEGIN RSA PRIVATE KEY-
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C93B386451093918
buV1Kuaiu8QXhSeBdAF9Le2u+SSzaEtrHw6rLq19xL+9lWuwf4dFtrMPRI/PPvA5
HwBB7ZzT1AAzOAK2AnDiND3+n6IyqrkQjD7R0bGY6VLXdMr3qgGiJOkmsroF5t/H
LQEFGn9F8eOfEQTjkz4h9KYF/traXZSayBjNQ37fL42HO4M5WY0Ehms6bfeU5BN5
1d+NdENKLK0KVIJDNM3clQoHCc2KJwq70CeZmKq+tIG7UdigxmW0f9B/BMSM8PFx
3cFzt1eZVj23jPO65icEfqLWvdYUpOqFfZc17Si87LW8ExvO8yu4UPrk8iRR8eFH
LeOCPobR446Ehq8XBgFiFp8kzus5vDbqRLbMaBqul/mVWDmkpcyrnWJVAfginUar
FDTji8Ge8Zv5GgpuS2tjYkQpykthA17SKxDGe8s26feaHkErEanTWg5o50RP1oUo
1e2rrX+PVFoukN9f+j5OiScC8QDVfBcSZZYvfRmkE1SnF3S3CAVdtDIcqmy33WY+
Icx/n2uh3Y4tYafzSu/5O8ZeBzGUz3eKWMIAL66mxOclPAceWsQ6Ry22IBdjr+7p
Af3IKo4sWVtj3mOlrwNdNX9JtdHYiskNTVJ7+7DBlmbM+lfQlvb7wBsVek9ex6k2
qxWv250S+rdWuXBx3WuleQsQ14gBtX7Rf0Sk3DvOTinaU9C5n8xwaO9GWS0CJtjA
AkDTLZ0rylVjfdd3W7fjxfYtQEwnbKeIC1SEKuNR8tv6GXGuubU5Nt8Q5TIhZIYL
p2H027lafTE1Ky+KIRD0qZWfSEAujrxJVnH1n62edYxzWXfr+onS0g==
-END RSA PRIVATE KEY-
Actual result:
--
Arch linux sample output
-BEGIN ENCRYPTED PRIVATE KEY-
MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIkd4I9LadOsYCAggA
MBQGCCqGSIb3DQMHBAhqJEWqm0xA9ASCAoDgWeRhfyKrCqfW7aSW1rYs8LVjN3ug
p9Kn6U7YZydHwxYdwNSK80i0yw+yU+ovVck2BdCBnm8ggdyXgS5UVTt5bnJHIHls
rEe4spLl8hkc0sOcL/ZseVBoxKIan7ZY1c0AysAwmrniFXKehSTCByDMUC58rl6H
gejVJk4+yebHuLqeq7z9d9dIvEuAFI9qjZjqUhq8wsCdN2+scFi/3/DXDp1V5/AS
SCeIsVsvcBNPaI8CYP48R13+mQJ+AGAWewcoHtwu8IQGuG46vlqOaYULCfInr/w7
/Y+Ttd2Hd6RHcnE9vTW7bhOn49v6KCtcwpcAtSz2kHrAufGxjAMzFV2oEVZPsDGM
4Rf3H1JtlJKIFYktTLoz9/07kQR0c6S1UkBa2oG/O7G0in7igzQEafKPKOMdOo3j
jP23He7kHJTTja5HE41DryUwa1JIB4L/BtbLDiYJA7KcrY7WoSROL675OmJEG1v6
vjLD0kcxIqc4rT0xesv4JEwVBxh8R/1qlqJjvLGJU8UQYWAzLqiMsg2rqrAy9XQy
Bug #52091 [Com]: ZipArchive: CRC32 errors / corrupted archives not reported
Edit report at http://bugs.php.net/bug.php?id=52091edit=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=52091edit=1
Bug #52091 [Asn]: ZipArchive: CRC32 errors / corrupted archives not reported
Edit report at http://bugs.php.net/bug.php?id=52091edit=1 ID: 52091 Updated by: paj...@php.net 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: @schmale at froglogic dot com If it is not the same then please open a new bug. Please provide both a script and an archive to reproduce your problem. Previous Comments: [2011-01-31 16:27:20] schmale at froglogic dot com 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). [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. 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/bug.php?id=52091 -- Edit this bug report at http://bugs.php.net/bug.php?id=52091edit=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=53893edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53893r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53893r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53893r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53893r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53893r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53893r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53893r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53893r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53893r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53893r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53893r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53893r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53893r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53893r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53893r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53893r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53893r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53893r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53893r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53893r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53893r=mysqlcfg
[PHP-BUG] Bug #53894 [NEW]: parse_ini_string('no=test') unexpected BOOL_FALSE
From: hm2k
Operating system:
PHP version: 5.3.5
Package: Strings related
Bug Type: Bug
Bug description:parse_ini_string('no=test') unexpected BOOL_FALSE
Description:
When using parse_ini_string or parse_ini_file, if you have the key as no
it
causes a syntax error, unexpected BOOL_FALSE.
Test script:
---
?php parse_ini_string('no=test')?
Expected result:
NULL
Actual result:
--
br /
bWarning/b: syntax error, unexpected BOOL_FALSE in Unknown on line 1
in b/home/.../no.php/b on line b1/bbr /
--
Edit bug report at http://bugs.php.net/bug.php?id=53894edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53894r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53894r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53894r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53894r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53894r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53894r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53894r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53894r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53894r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53894r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53894r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53894r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53894r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53894r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53894r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53894r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53894r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53894r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53894r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53894r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53894r=mysqlcfg
Bug #53893 [Opn-Fbk]: Wrong return value for ZipArchive::extractTo()
Edit report at http://bugs.php.net/bug.php?id=53893edit=1
ID: 53893
Updated by: fel...@php.net
Reported by:schmale at froglogic dot com
Summary:Wrong return value for ZipArchive::extractTo()
-Status: Open
+Status: Feedback
Type: Bug
Package:Zip Related
Operating System: Linux
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Hello, I've a doubt about the test case. $zipPath points to an empty zip
file?
Previous Comments:
[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=53893edit=1
Bug #53894 [Opn-Bgs]: parse_ini_string('no=test') unexpected BOOL_FALSE
Edit report at http://bugs.php.net/bug.php?id=53894edit=1
ID: 53894
Updated by: fel...@php.net
Reported by:h...@php.net
Summary:parse_ini_string('no=test') unexpected BOOL_FALSE
-Status: Open
+Status: Bogus
Type: Bug
Package:Strings related
PHP Version:5.3.5
Block user comment: N
Private report: N
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
This is expected... See the 'notes' section on parse_ini_string()
documentation: http://docs.php.net/parse-ini-string
Previous Comments:
[2011-01-31 19:24:08] h...@php.net
Description:
When using parse_ini_string or parse_ini_file, if you have the key as
no it
causes a syntax error, unexpected BOOL_FALSE.
Test script:
---
?php parse_ini_string('no=test')?
Expected result:
NULL
Actual result:
--
br /
bWarning/b: syntax error, unexpected BOOL_FALSE in Unknown on line
1
in b/home/.../no.php/b on line b1/bbr /
--
Edit this bug report at http://bugs.php.net/bug.php?id=53894edit=1
[PHP-BUG] Bug #53895 [NEW]: debug_zval_dump should be by ref
From: Operating system: PHP version: 5.3.5 Package: Unknown/Other Function Bug Type: Bug Bug description:debug_zval_dump should be by ref Description: debug_zval_dump should accept the variable by reference. Currently one can call the function either via debug_zval_dump($var) or debug_zval_dump($var). As the latter is as deprecated as it gets (i.e. parse-time deprecated) and is even removed in trunk, the function should be defined as accepting the variable by reference, because this is the usual use case. -- Edit bug report at http://bugs.php.net/bug.php?id=53895edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53895r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53895r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53895r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53895r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53895r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53895r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53895r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53895r=needscript Try newer version: http://bugs.php.net/fix.php?id=53895r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53895r=support Expected behavior: http://bugs.php.net/fix.php?id=53895r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53895r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53895r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53895r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53895r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53895r=dst IIS Stability: http://bugs.php.net/fix.php?id=53895r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53895r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53895r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53895r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53895r=mysqlcfg
Bug #53887 [Opn-Bgs]: When array data is int value, array_intersect() speed VERY SLOW.
Edit report at http://bugs.php.net/bug.php?id=53887edit=1
ID: 53887
Updated by: ahar...@php.net
Reported by:paulgao at yeah dot net
Summary:When array data is int value, array_intersect()
speed VERY SLOW.
-Status: Open
+Status: Bogus
Type: Bug
Package:Arrays related
Operating System: irrelevant
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
As the documentation says, array_intersect() internally compares the
values of the arrays as strings. This implies that non-string values
(such as integers) need to be converted to their equivalent string
values first before being compared, which obviously takes some time.
I suspect we'd be interested in a patch that improved the performance if
it maintained the existing comparison behaviour, but for now, I'm
closing this as it is documented.
Previous Comments:
[2011-01-31 08:19:57] paulgao at yeah dot net
Description:
When array data is int value, array_intersect() speed VERY SLOW.
Test script:
---
?php
ini_set('memory_limit', -1);
$data_a = rand_data(FALSE);
$data_b = rand_data(FALSE);
$time = microtime(TRUE);
$result = array_intersect($data_a, $data_b);
$time = microtime(TRUE) - $time;
echo - array_intersect by intval: {$time}, result: . count($result)
. \r\n;
$data_a = rand_data(TRUE);
$data_b = rand_data(TRUE);
$time = microtime(TRUE);
$result = array_intersect($data_a, $data_b);
$time = microtime(TRUE) - $time;
echo - array_intersect by string: {$time}, result: . count($result)
. \r\n;
function rand_data($need_string)
{
mt_srand();
$result = array();
for ($i = 0; $i 30; $i++)
{
if ($need_string === TRUE)
{
$result[] = (string)mt_rand();
}
else
{
$result[] = mt_rand();
}
}
return $result;
}
?
Expected result:
almost same?
Actual result:
--
- array_intersect by intval: 10.661009073257, result: 47
- array_intersect by string: 1.3067090511322, result: 41
--
Edit this bug report at http://bugs.php.net/bug.php?id=53887edit=1
Bug #53888 [Opn-Dup]: ftruncate() does not work with user-defined stream wrappers
Edit report at http://bugs.php.net/bug.php?id=53888edit=1
ID: 53888
Updated by: ahar...@php.net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:ftruncate() does not work with user-defined stream
wrappers
-Status: Open
+Status: Duplicate
Type: Bug
Package:Filesystem function related
PHP Version:trunk-SVN-2011-01-31 (SVN)
Block user comment: N
Private report: N
New Comment:
Duplicate of request #38025.
Previous Comments:
[2011-01-31 08:45:05] ivan dot enderlin at hoa-project dot net
Description:
Hey :-),
Seems like ftruncate() does not reconized an user-defined stream (with
stream wrapper) as a valid stream. When we use it, it raises the
following error: âCan't truncate this stream!â. All the related
subject about this error on the Web talks about stream wrappers. Thus,
it's seem to be the real problem.
Test script:
---
?php
class StreamWrapper {
private $_stream = null;
private $_streamName = null;
public $context = null;
public static function realPath ( $path ) {
return substr($path, 6);
}
public function stream_close ( ) {
if(true === @fclose($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return;
}
public function stream_eof ( ) {
return feof($this-getStream());
}
public function stream_flush ( ) {
return fflush($this-getStream());
}
public function stream_lock ( $operation ) {
return flock($this-getStream(), $operation);
}
public function stream_open ( $path, $mode, $options, $openedPath )
{
$p = self::realPath($path);
if(false === $p)
return false;
if(null === $this-context)
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH
);
else
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH,
$this-context
);
$this-_stream = $openedPath;
$this-_streamName = $p;
return true;
}
public function stream_read ( $count ) {
return fread($this-getStream(), $count);
}
public function stream_seek ( $offset, $whence = SEEK_SET ) {
return fseek($this-getStream(), $offset, $whence);
}
public function stream_stat ( ) {
return fstat($this-getStream());
}
public function stream_tell ( ) {
return ftell($this-getStream());
}
public function stream_write ( $data ) {
return fwrite($this-getStream(), $data);
}
public function dir_closedir ( ) {
if(true === $handle = @closedir($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return $handle;
}
public function dir_opendir ( $path, $options ) {
$p = self::realPath($path);
$handle = null;
if(null === $this-context)
$handle = @opendir($p);
else
$handle = @opendir($p, $this-context);
if(false === $handle)
return false;
$this-_stream = $handle;
$this-_streamName = $p;
return true;
}
public function dir_readdir ( ) {
return readdir($this-getStream());
}
public function dir_rewinddir ( ) {
return rewinddir($this-getStream());
}
public function mkdir ( $path, $mode, $options ) {
if(null === $this-context)
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE
);
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE,
$this-context
);
}
public function rename ( $from, $to ) {
if(null === $this-context)
return rename(self::realPath($from), self::realPath($to));
return rename(self::realPath($from), self::realPath($to),
$this-context);
}
public function rmdir ( $path, $options ) {
if(null === $this-context)
return rmdir(self::realPath($path));
return rmdir(self::realPath($path), $this-context);
}
public function unlink ( $path ) {
if(null === $this-context)
return unlink(self::realPath($path));
return unlink(self::realPath($path), $this-context);
}
public function url_stat ( $path,
[PHP-BUG] Req #53896 [NEW]: return/break types if
From:
Operating system: All
PHP version: 5.3.5
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:return/break types if
Description:
It's a simple feature that PHP can have, if just substitute if+return, for
instance to return+if. It's, change to one-line script.
See test script and read more...
Well, sometimes we need to break function, or while, or foreach, or maybe
force
continue case somethink occur, a condition.
My idea is make this more readable, in an one line script.
Instead of:
if($a $b) return;
We do:
return if $a $b;
Or:
return if($a $b);
Maybe only accept a boolean on return:
return $a $b;
Then:
return true; // do return
return false; // not do
Same to continue:
for($i=0; $i10; $i++){
continue $i === 5;
echo $i . \n;
}
It's a valid idea? ^o)
Bye.
Test script:
---
http://pastebin.com/fEB8eGxf
--
Edit bug report at http://bugs.php.net/bug.php?id=53896edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53896r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53896r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53896r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53896r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53896r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53896r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53896r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53896r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53896r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53896r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53896r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53896r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53896r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53896r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53896r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53896r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53896r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53896r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53896r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53896r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53896r=mysqlcfg
Req #53896 [Opn-Wfx]: return/break types if
Edit report at http://bugs.php.net/bug.php?id=53896edit=1
ID: 53896
Updated by: ahar...@php.net
Reported by:david71rj at gmail dot com
Summary:return/break types if
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: All
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
PHP is not Perl, and doesn't support postfix statement modifiers. This
is intentional, and unlikely to change.
Previous Comments:
[2011-02-01 05:39:28] david71rj at gmail dot com
Description:
It's a simple feature that PHP can have, if just substitute if+return,
for
instance to return+if. It's, change to one-line script.
See test script and read more...
Well, sometimes we need to break function, or while, or foreach, or
maybe force
continue case somethink occur, a condition.
My idea is make this more readable, in an one line script.
Instead of:
if($a $b) return;
We do:
return if $a $b;
Or:
return if($a $b);
Maybe only accept a boolean on return:
return $a $b;
Then:
return true; // do return
return false; // not do
Same to continue:
for($i=0; $i10; $i++){
continue $i === 5;
echo $i . \n;
}
It's a valid idea? ^o)
Bye.
Test script:
---
http://pastebin.com/fEB8eGxf
--
Edit this bug report at http://bugs.php.net/bug.php?id=53896edit=1
Bug #50813 [Com]: __isset() not called for uninitialized array offsets $obj-test[0]
Edit report at http://bugs.php.net/bug.php?id=50813edit=1
ID: 50813
Comment by: mjk at emmjaykay dot org
Reported by:marc dot bennewitz at giata dot de
Summary:__isset() not called for uninitialized array offsets
$obj-test[0]
Status: Verified
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.*, 6
Block user comment: N
Private report: N
New Comment:
I'm not so sure this patch is kosher since it checks the return value's
lval from the call to zend_std_call_issetter(). I don't see it in other
code.
Previous Comments:
[2010-01-21 12:03:48] marc dot bennewitz at giata dot de
Thats the same:
php -v
PHP 5.3.3-dev (cli) (built: Jan 21 2010 12:52:05)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
php test.php
PHP Notice: Key test does not exist in /tmp/test.php on line 14
Notice: Key test does not exist in /tmp/test.php on line 14
bool(false)
[2010-01-21 09:59:53] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-21 09:10:17] marc dot bennewitz at giata dot de
Description:
On testing if an array key is available on an overloaded object variable
it doesn't check __isset before calling __get to get the variable for
checking the array key.
Reproduce code:
---
class MyClass
{
public function __isset($varname)
{
echo 'isset' . PHP_EOL;
return false;
}
public function __get($varname)
{
trigger_error('Key ' . $varname . ' does not exist',
E_USER_NOTICE);
}
}
$obj = new MyClass();
var_dump( isset($obj-test[0]) );
Expected result:
isset
bool(false)
Actual result:
--
PHP Notice: Key test does not exist in /tmp/test.php on line 14
Notice: Key test does not exist in /tmp/test.php on line 14
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50813edit=1
Bug #50813 [Com]: __isset() not called for uninitialized array offsets $obj-test[0]
Edit report at http://bugs.php.net/bug.php?id=50813edit=1
ID: 50813
Comment by: mjk at emmjaykay dot org
Reported by:marc dot bennewitz at giata dot de
Summary:__isset() not called for uninitialized array offsets
$obj-test[0]
Status: Verified
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.*, 6
Block user comment: N
Private report: N
New Comment:
In my change, if I comment out the __isset definition, I get
Fatal error: Couldn't find implementation for method MyClass::__isset in
Unknown on line 0
where as on the unchanged code, I get
Notice: Key test does not exist in /home/mjk/php-5.3.5.orig/e.php on
line 22
bool(false)
I'm not sure if that's correct or not.
Previous Comments:
[2011-02-01 07:55:20] mjk at emmjaykay dot org
I'm not so sure this patch is kosher since it checks the return value's
lval from the call to zend_std_call_issetter(). I don't see it in other
code.
[2010-01-21 12:03:48] marc dot bennewitz at giata dot de
Thats the same:
php -v
PHP 5.3.3-dev (cli) (built: Jan 21 2010 12:52:05)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
php test.php
PHP Notice: Key test does not exist in /tmp/test.php on line 14
Notice: Key test does not exist in /tmp/test.php on line 14
bool(false)
[2010-01-21 09:59:53] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-01-21 09:10:17] marc dot bennewitz at giata dot de
Description:
On testing if an array key is available on an overloaded object variable
it doesn't check __isset before calling __get to get the variable for
checking the array key.
Reproduce code:
---
class MyClass
{
public function __isset($varname)
{
echo 'isset' . PHP_EOL;
return false;
}
public function __get($varname)
{
trigger_error('Key ' . $varname . ' does not exist',
E_USER_NOTICE);
}
}
$obj = new MyClass();
var_dump( isset($obj-test[0]) );
Expected result:
isset
bool(false)
Actual result:
--
PHP Notice: Key test does not exist in /tmp/test.php on line 14
Notice: Key test does not exist in /tmp/test.php on line 14
bool(false)
--
Edit this bug report at http://bugs.php.net/bug.php?id=50813edit=1
Bug #53888 [Com]: ftruncate() does not work with user-defined stream wrappers
Edit report at http://bugs.php.net/bug.php?id=53888edit=1
ID: 53888
Comment by: ivan dot enderlin at hoa-project dot net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:ftruncate() does not work with user-defined stream
wrappers
Status: Duplicate
Type: Bug
Package:Filesystem function related
PHP Version:trunk-SVN-2011-01-31 (SVN)
Block user comment: N
Private report: N
New Comment:
But the bug is still open no? And since 2006?
Is this bug affected to someone? Does an explanation of this behavior
exist? Please, more details :-).
Previous Comments:
[2011-02-01 05:33:44] ahar...@php.net
Duplicate of request #38025.
[2011-01-31 08:45:05] ivan dot enderlin at hoa-project dot net
Description:
Hey :-),
Seems like ftruncate() does not reconized an user-defined stream (with
stream wrapper) as a valid stream. When we use it, it raises the
following error: âCan't truncate this stream!â. All the related
subject about this error on the Web talks about stream wrappers. Thus,
it's seem to be the real problem.
Test script:
---
?php
class StreamWrapper {
private $_stream = null;
private $_streamName = null;
public $context = null;
public static function realPath ( $path ) {
return substr($path, 6);
}
public function stream_close ( ) {
if(true === @fclose($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return;
}
public function stream_eof ( ) {
return feof($this-getStream());
}
public function stream_flush ( ) {
return fflush($this-getStream());
}
public function stream_lock ( $operation ) {
return flock($this-getStream(), $operation);
}
public function stream_open ( $path, $mode, $options, $openedPath )
{
$p = self::realPath($path);
if(false === $p)
return false;
if(null === $this-context)
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH
);
else
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH,
$this-context
);
$this-_stream = $openedPath;
$this-_streamName = $p;
return true;
}
public function stream_read ( $count ) {
return fread($this-getStream(), $count);
}
public function stream_seek ( $offset, $whence = SEEK_SET ) {
return fseek($this-getStream(), $offset, $whence);
}
public function stream_stat ( ) {
return fstat($this-getStream());
}
public function stream_tell ( ) {
return ftell($this-getStream());
}
public function stream_write ( $data ) {
return fwrite($this-getStream(), $data);
}
public function dir_closedir ( ) {
if(true === $handle = @closedir($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return $handle;
}
public function dir_opendir ( $path, $options ) {
$p = self::realPath($path);
$handle = null;
if(null === $this-context)
$handle = @opendir($p);
else
$handle = @opendir($p, $this-context);
if(false === $handle)
return false;
$this-_stream = $handle;
$this-_streamName = $p;
return true;
}
public function dir_readdir ( ) {
return readdir($this-getStream());
}
public function dir_rewinddir ( ) {
return rewinddir($this-getStream());
}
public function mkdir ( $path, $mode, $options ) {
if(null === $this-context)
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE
);
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE,
$this-context
);
}
public function rename ( $from, $to ) {
if(null === $this-context)
return rename(self::realPath($from), self::realPath($to));
return rename(self::realPath($from), self::realPath($to),
$this-context);
}
public function rmdir ( $path, $options ) {
if(null === $this-context)
return rmdir(self::realPath($path));
return rmdir(self::realPath($path),
Bug #53888 [Dup-Opn]: ftruncate() does not work with user-defined stream wrappers
Edit report at http://bugs.php.net/bug.php?id=53888edit=1
ID: 53888
Updated by: paj...@php.net
Reported by:ivan dot enderlin at hoa-project dot net
Summary:ftruncate() does not work with user-defined stream
wrappers
-Status: Duplicate
+Status: Open
Type: Bug
Package:Filesystem function related
PHP Version:trunk-SVN-2011-01-31 (SVN)
Block user comment: N
Private report: N
New Comment:
Let keep it open unless the other bug has clear tests cases and similar
information, which is not the case now.
Previous Comments:
[2011-02-01 08:46:12] ivan dot enderlin at hoa-project dot net
But the bug is still open no? And since 2006?
Is this bug affected to someone? Does an explanation of this behavior
exist? Please, more details :-).
[2011-02-01 05:33:44] ahar...@php.net
Duplicate of request #38025.
[2011-01-31 08:45:05] ivan dot enderlin at hoa-project dot net
Description:
Hey :-),
Seems like ftruncate() does not reconized an user-defined stream (with
stream wrapper) as a valid stream. When we use it, it raises the
following error: âCan't truncate this stream!â. All the related
subject about this error on the Web talks about stream wrappers. Thus,
it's seem to be the real problem.
Test script:
---
?php
class StreamWrapper {
private $_stream = null;
private $_streamName = null;
public $context = null;
public static function realPath ( $path ) {
return substr($path, 6);
}
public function stream_close ( ) {
if(true === @fclose($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return;
}
public function stream_eof ( ) {
return feof($this-getStream());
}
public function stream_flush ( ) {
return fflush($this-getStream());
}
public function stream_lock ( $operation ) {
return flock($this-getStream(), $operation);
}
public function stream_open ( $path, $mode, $options, $openedPath )
{
$p = self::realPath($path);
if(false === $p)
return false;
if(null === $this-context)
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH
);
else
$openedPath = fopen(
$p,
$mode,
$options STREAM_USE_PATH,
$this-context
);
$this-_stream = $openedPath;
$this-_streamName = $p;
return true;
}
public function stream_read ( $count ) {
return fread($this-getStream(), $count);
}
public function stream_seek ( $offset, $whence = SEEK_SET ) {
return fseek($this-getStream(), $offset, $whence);
}
public function stream_stat ( ) {
return fstat($this-getStream());
}
public function stream_tell ( ) {
return ftell($this-getStream());
}
public function stream_write ( $data ) {
return fwrite($this-getStream(), $data);
}
public function dir_closedir ( ) {
if(true === $handle = @closedir($this-getStream())) {
$this-_stream = null;
$this-_streamName = null;
}
return $handle;
}
public function dir_opendir ( $path, $options ) {
$p = self::realPath($path);
$handle = null;
if(null === $this-context)
$handle = @opendir($p);
else
$handle = @opendir($p, $this-context);
if(false === $handle)
return false;
$this-_stream = $handle;
$this-_streamName = $p;
return true;
}
public function dir_readdir ( ) {
return readdir($this-getStream());
}
public function dir_rewinddir ( ) {
return rewinddir($this-getStream());
}
public function mkdir ( $path, $mode, $options ) {
if(null === $this-context)
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE
);
return mkdir(
self::realPath($path),
$mode,
$options | STREAM_MKDIR_RECURSIVE,
$this-context
);
}
public function rename ( $from, $to ) {
if(null === $this-context)
return rename(self::realPath($from), self::realPath($to));
return
Bug #53893 [Fbk-Opn]: Wrong return value for ZipArchive::extractTo()
Edit report at http://bugs.php.net/bug.php?id=53893edit=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=53893edit=1
