#46981 [Fbk->Opn]: PDO get Data Bug for Firebird DBMS
ID: 46981
User updated by: flylink at 126 dot com
Reported By: flylink at 126 dot com
-Status: Feedback
+Status: Open
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.2.8
New Comment:
Maybe it is not clear from my last description, please read the
following:
In PHP script, when access Firbird database with PDO drive and get
the data from a reslut set by executing SQL qury sentence when there is
a result set, the first row data is null.
Previous Comments:
[2009-01-01 01:59:15] ka...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2008-12-31 03:16:01] flylink at 126 dot com
Description:
I use PDO driver to access Firebird DBMS,
find a bug,I couldn't get first row's data
Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
http://www.w3.org/1999/xhtml";>
PDO for Firebird
PDO BUG for Firebird:";
$sql='SELECT * from link';
$rs=$dbConn->query($sql);
foreach ($rs as $row) { print "1==>".$row[1]."
2==>".$row['SITELINK'].""; }
$dbConn=NULL;
?>
Expected result:
PDO BUG for Firebird:
1==>Firebird 2==>http://www.firebirdsql.org
1==>?Ìò±SDN 2==>http://www.csdn.net
1==>???í¼¾ 2==>http://firebird.dearinfo.com/
1==>IBPhoenix 2==>http://www.ibphoenix.com
1==>??Ô½PHP 2==>http://www.phpe.net
1==>Fracle-Janus Soft 2==>http://www.janus-software.com
1==>FirebirdÖÎɧǸ 2==>http://www.firebird.net.cn
1==>?ãÊ?Í?Ð×Ѷ 2==>http://www.it136.net
1==>DelphiÔ°?Ø 2==>http://www.delphifans.com
1==>Delphi K.TopÓÕ?^ 2==>http://delphi.ktop.com.tw
1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/
1==>Firebird?ٷ?͸վ 2==>http://www.firebirdsql.org/
1==>Î?IJ??Í 2==>http://blog.csdn.net/jianlei/
1==>DelphiÒ¤?? 2==>http://www.51delphi.com
1==>Delphi?ÐÓ 2==>http://www.2ccc.com
1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm
1==>???UÅ 2==>http://jianlei.ys168.com
Actual result:
--
PDO BUG for Firebird:
1==> 2==>
1==>?Ìò±SDN 2==>http://www.csdn.net
1==>???í¼¾ 2==>http://firebird.dearinfo.com/
1==>IBPhoenix 2==>http://www.ibphoenix.com
1==>??Ô½PHP 2==>http://www.phpe.net
1==>Fracle-Janus Soft 2==>http://www.janus-software.com
1==>FirebirdÖÎɧǸ 2==>http://www.firebird.net.cn
1==>?ãÊ?Í?Ð×Ѷ 2==>http://www.it136.net
1==>DelphiÔ°?Ø 2==>http://www.delphifans.com
1==>Delphi K.TopÓÕ?^ 2==>http://delphi.ktop.com.tw
1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/
1==>Firebird?ٷ?͸վ 2==>http://www.firebirdsql.org/
1==>Î?IJ??Í 2==>http://blog.csdn.net/jianlei/
1==>DelphiÒ¤?? 2==>http://www.51delphi.com
1==>Delphi?ÐÓ 2==>http://www.2ccc.com
1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm
1==>???UÅ 2==>http://jianlei.ys168.com
--
Edit this bug report at http://bugs.php.net/?id=46981&edit=1
#46990 [Opn]: Passing UTF8 strings to filesystem functions produce wrong filenames
ID: 46990 Updated by: j...@php.net Reported By: alex dot bazan at concatel dot com Status: Open Bug Type: *Directory/Filesystem functions -Operating System: Windows XP +Operating System: win32 only - Windows XP PHP Version: 5.2.8 New Comment: Previous Comments: [2009-01-02 08:06:39] alex dot bazan at concatel dot com The UTF string did not get saved correctly in the bug report. It was a japanese string. [2009-01-02 08:03:37] alex dot bazan at concatel dot com Description: Under Windows, when I use fpoen() or mkdir() with a UTF8 encoded string, the file or directory name is not converted to the filesystem encoding and thus the file or directory is created with a wrong file name. Reproduce code: --- Expected result: Directory 日本語 should be created Actual result: -- Directory æ¥æ¬èª is created -- Edit this bug report at http://bugs.php.net/?id=46990&edit=1
#46996 [Opn->Bgs]: system() function show error unable to fork
ID: 46996
Updated by: j...@php.net
Reported By: hardik at promactinfo dot co dot in
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: windows server 2000
PHP Version: 5.2.8
New Comment:
Permissions. Please SEARCH the bug database BEFORE you submit another
bogus report.
Previous Comments:
[2009-01-03 04:30:41] hardik at promactinfo dot co dot in
Description:
system("cd D:\\projects\\youngComposers\\web\\forum", $result1);
//system("d:",$result2);
system("c:\\php\\php.exe
D:\\projects\\youngComposers\\web\\forum\\vbregister.php add 0 test432
123123 hards_...@yahoo.com 1983 12 23 1 grpgrp 1 1 1 1 5", $result);
after putting these code in my current application it shows the error
"Warning: system() [function.system]: Unable to fork [cd
D:\projects\youngComposers\web\forum]" but when i put it in independent
page so it's not give me error so please give me proper solution on
this.
--
Edit this bug report at http://bugs.php.net/?id=46996&edit=1
#46997 [NEW]: Column Name Based Result Fetching Causes Access Violation
From: dangerousdave86 at hotmail dot com Operating system: Windows Server 2008 Std ISAPI PHP version: 5.2.8 PHP Bug Type: MySQLi related Bug description: Column Name Based Result Fetching Causes Access Violation Description: Error: PHP has encountered an Access Violation at 00322BEB When calling mysqli_fetch_assoc or mysqli_fetch_object on mysqli result. Also occurs using OO method. Error does not occur when using mysqli_fetch_row. Result is correct and indexed numerically in array. Reproduce code: --- Any database query using mysql that fetches rows using mysql_fetch_object, _fetch_assoc, _fetch_array. Or OO equivilents. Expected result: an array representing a row from the database Actual result: -- Access Violation -- Edit bug report at http://bugs.php.net/?id=46997&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46997&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46997&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46997&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46997&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46997&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46997&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46997&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46997&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46997&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46997&r=support Expected behavior: http://bugs.php.net/fix.php?id=46997&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46997&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46997&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46997&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46997&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46997&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46997&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46997&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46997&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46997&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46997&r=mysqlcfg
#46680 [NoF->Opn]: Files created in wrong directory (include path vs current working directory)
ID: 46680
Updated by: z...@php.net
Reported By: a...@php.net
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.3CVS-2008-11-26 (snap)
Assigned To: dmitry
Previous Comments:
[2008-12-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-12-10 12:19:53] dmi...@php.net
I suppose the behavior in 5.3 is proper and the tests are wrong.
In 5.3 Both fopen() and file_put_contents() first look for file in
include path and in case of failure create new file in current working
directory. May be it should be changed to create it in first element of
include_path, but what should php to do if such directory doesn't
exist... Creation file in "script" directory (as 5.2 does, and what
tests expect) makes no sense.
BTW I don't see a lot of sense in usage of include_path with "create"
functions at all.
[2008-12-09 19:37:29] cel...@php.net
first of all, the change from PHP 5.2 is the addition of
php_resolve_path, which is Dmitry's work. Second of all, most of the
tests are checking for *broken* behavior which is fixed in PHP 5.3.
file_put_contents('blah', 'whatever', FILE_USE_INCLUDE_PATH);
should not arbitrarily create the "blah" file in the first element of
the include_path. file_get_contents('blah', true) does not work this
way, it scans include_path for the file, and if not found, it tries as a
fallback to search in the current directory, and only then does it fail.
This is correct behavior - the file should be created in the current
directory if it does not already exist in the include_path. The
addition of the fallback was added in PHP 5.3, it seems.
The fopen tests also assume that fopen() with include_path parameter
for read will not check the current directory.
So we have a larger dilemma - the default include_path has the current
directory as the first element, and thus the functions that use
include_path for writing were acting as if they were doing the right
thing, when in fact they were making an arbitrary assumption about where
to put things.
None of this behavior is documented, so it is questionable what is the
right way to do things.
In other words, Jani is wrong to imply that anything I did caused the
problem, and should probably apologize, but I won't hold my breath.
I'm assigning to Dmitry under the assumption he will want to do the
ultimate commit, but will raise this on internals@
[2008-11-26 10:15:48] a...@php.net
Description:
The following tests were ported from 5.2.X and do not work as
expected on 5.3. The tests all create a test file and expect it to be
created in an include directory. Instead it looks like the file is
being created elsewhere This particularly affects file_put_contents()
with the FILE_USE_INCLUDE_PATH flag set, and also fopen(...).
Reproduce code:
---
See the tests now checked into CVS:
ext/standard/tests/file/file_put_contents_variation4.phpt
ext/standard/tests/file/file_put_contents_variation5.phpt
ext/standard/tests/file/file_put_contents_variation6.phpt
ext/standard/tests/file/fopen_variation5.phpt
ext/standard/tests/file/fopen_variation7.phpt
ext/standard/tests/file/fopen_variation8.phpt
ext/standard/tests/file/fopen_variation9.phpt
ext/standard/tests/file/fopen_variation12.phpt
ext/standard/tests/file/fopen_variation16.phpt
ext/standard/tests/file/fopen_variation17.phpt
Expected result:
See expected output in the PHPTs.
Actual result:
--
See the test results from running the PHPTs.
--
Edit this bug report at http://bugs.php.net/?id=46680&edit=1
#46680 [Opn]: Files created in wrong directory (include path vs current working directory)
ID: 46680
Updated by: z...@php.net
Reported By: a...@php.net
Status: Open
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.3CVS-2008-11-26 (snap)
-Assigned To:
+Assigned To: zoe
New Comment:
If the behaviour is correct in 5.3 the tests need to be fixed. I'm have
re-opened and assigned to myself to fix.
Previous Comments:
[2008-12-18 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2008-12-10 12:19:53] dmi...@php.net
I suppose the behavior in 5.3 is proper and the tests are wrong.
In 5.3 Both fopen() and file_put_contents() first look for file in
include path and in case of failure create new file in current working
directory. May be it should be changed to create it in first element of
include_path, but what should php to do if such directory doesn't
exist... Creation file in "script" directory (as 5.2 does, and what
tests expect) makes no sense.
BTW I don't see a lot of sense in usage of include_path with "create"
functions at all.
[2008-12-09 19:37:29] cel...@php.net
first of all, the change from PHP 5.2 is the addition of
php_resolve_path, which is Dmitry's work. Second of all, most of the
tests are checking for *broken* behavior which is fixed in PHP 5.3.
file_put_contents('blah', 'whatever', FILE_USE_INCLUDE_PATH);
should not arbitrarily create the "blah" file in the first element of
the include_path. file_get_contents('blah', true) does not work this
way, it scans include_path for the file, and if not found, it tries as a
fallback to search in the current directory, and only then does it fail.
This is correct behavior - the file should be created in the current
directory if it does not already exist in the include_path. The
addition of the fallback was added in PHP 5.3, it seems.
The fopen tests also assume that fopen() with include_path parameter
for read will not check the current directory.
So we have a larger dilemma - the default include_path has the current
directory as the first element, and thus the functions that use
include_path for writing were acting as if they were doing the right
thing, when in fact they were making an arbitrary assumption about where
to put things.
None of this behavior is documented, so it is questionable what is the
right way to do things.
In other words, Jani is wrong to imply that anything I did caused the
problem, and should probably apologize, but I won't hold my breath.
I'm assigning to Dmitry under the assumption he will want to do the
ultimate commit, but will raise this on internals@
[2008-11-26 10:15:48] a...@php.net
Description:
The following tests were ported from 5.2.X and do not work as
expected on 5.3. The tests all create a test file and expect it to be
created in an include directory. Instead it looks like the file is
being created elsewhere This particularly affects file_put_contents()
with the FILE_USE_INCLUDE_PATH flag set, and also fopen(...).
Reproduce code:
---
See the tests now checked into CVS:
ext/standard/tests/file/file_put_contents_variation4.phpt
ext/standard/tests/file/file_put_contents_variation5.phpt
ext/standard/tests/file/file_put_contents_variation6.phpt
ext/standard/tests/file/fopen_variation5.phpt
ext/standard/tests/file/fopen_variation7.phpt
ext/standard/tests/file/fopen_variation8.phpt
ext/standard/tests/file/fopen_variation9.phpt
ext/standard/tests/file/fopen_variation12.phpt
ext/standard/tests/file/fopen_variation16.phpt
ext/standard/tests/file/fopen_variation17.phpt
Expected result:
See expected output in the PHPTs.
Actual result:
--
See the test results from running the PHPTs.
--
Edit this bug report at http://bugs.php.net/?id=46680&edit=1
#46917 [Fbk->Opn]: Socket handling completely broken
ID: 46917
User updated by: jost_boekemeier at users dot sf dot net
Reported By: jost_boekemeier at users dot sf dot net
-Status: Feedback
+Status: Open
Bug Type: Streams related
Operating System: *
PHP Version: 5.2.8
New Comment:
Yes, this patch fixes the problem on Linux.
What about Windows?
Regards,
Jost Boekemeier
Previous Comments:
[2009-01-02 21:31:43] fel...@php.net
Hi, I've commited a probable fix, I initialized the errno.
http://news.php.net/php.cvs/55296
Can you test it with a cvs version again?
[2008-12-26 17:28:10] jost_boekemeier at users dot sf dot net
Due to its nature (uninitialized variable) you may or may not be able
to reproduce this bug. See
http://sourceforge.net/mailarchive/forum.php?thread_name=828E3F73B78941EAB5AF3E2E07C37D8D%40IBM1020C944423&forum_name=php-java-bridge-users
for details.
However, you should immediately see the bug by looking at the PHP
source code:
0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK
does NOT set errno (the result code is 0, not -1) so that errno
contains a bogus value, most likely the error code from a previously
failed sys call, so that
php_socket_errno() != EAGAIN
fails, depending on the application's PHP code, as errno sometimes
contains EAGAIN (from a previous poll()).
Just search the PHP sources for the pattern
} else if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv)
>
0) {
if (0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) &&
php_socket_errno() != EAGAIN) {
alive = 0;
}
and set the errno or the lastErrorCode (for windows) to zero before
calling this pattern.
After that persistent sockets, soap and a few other places will work
reliably.
There are a few caveats, however. First, if you pass the last error
number to application-level, you might have to restore the last errno
immediately after the recv call. Second, I don't know what the
php_socket_errno() != EAGAIN should do, anyway, as EAGAIN is only set
when the previous sys call failed (result code -1, not 0!). So I suggest
to ask the author to explain his/her code before fixing anything.
Regards,
Jost Bökemeier
[2008-12-24 19:48:34] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-12-21 16:07:15] jost_boekemeier at users dot sf dot net
The relevant part of the bug trace was missing.
poll([{fd=16, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1
([{fd=16, revents=POLLIN}])
recv(16, ""..., 1, MSG_PEEK)= 0
send(16, "PUT /JavaBridge/JavaBridge.phpjavabridge HTTP/1.1\r\nHost:
localhost\r\nContent-Length: 40\r\nX_JAVABRIDGE_CHANNEL:
/dev/shm/.php_java_bridgexN2WsO\r\n\r\n\177C"..., 185, 0) = 185
poll([{fd=16, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=16,
revents=POLLIN|POLLERR|POLLHUP}])
recv(16, ""..., 8192, 0)= 0
[2008-12-21 16:03:05] jost_boekemeier at users dot sf dot net
Description:
PHP cannot handle broken socket connections due to an uninitialized
variable.
xp_socket.c and several other places contain the following pattern:
...
} else if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv)
> 0) {
if (0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) &&
php_socket_errno() != EAGAIN) {
alive = 0;
}
...
It is obvious that the above code cannot work on any operating system;
checking if the socket doesn't have an error and then asking for its
error code is simply nonsense.
The same pattern is used in several other places within PHP.
The above code fails constantly on Windows. On Linux/Unix a workaround
is to add the constant 1E512 to the PHP script, which initializes errno
with a value != EAGAIN.
Regards,
Jost Bökemeier
Reproduce code:
---
pfsockopen()
...
// restart back end
...
pfsockopen()
=>
Expected result:
...
poll([{fd=16, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1
([{fd=16, revents=POLLIN}])
recv(16, ""..., 1, MSG_PEEK)= 0
close(16)
...
Actual result:
--
...
poll([{fd=16, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=16,
revents=POLLIN|POLLERR|POLLHUP}])
recv(16, ""..., 8192, 0)= 0
#46917 [Opn->Csd]: Socket handling completely broken
ID: 46917
Updated by: fel...@php.net
Reported By: jost_boekemeier at users dot sf dot net
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: *
PHP Version: 5.2.8
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
I added the Win part minutes ago:
-#ifndef PHP_WIN32
+/* Reseting/initializing */
+#ifdef PHP_WIN32
+ WSASetLastError(0);
+#else
errno = 0;
#endif
Ok, then, closed. Thanks.
Previous Comments:
[2009-01-03 16:45:50] jost_boekemeier at users dot sf dot net
Yes, this patch fixes the problem on Linux.
What about Windows?
Regards,
Jost Boekemeier
[2009-01-02 21:31:43] fel...@php.net
Hi, I've commited a probable fix, I initialized the errno.
http://news.php.net/php.cvs/55296
Can you test it with a cvs version again?
[2008-12-26 17:28:10] jost_boekemeier at users dot sf dot net
Due to its nature (uninitialized variable) you may or may not be able
to reproduce this bug. See
http://sourceforge.net/mailarchive/forum.php?thread_name=828E3F73B78941EAB5AF3E2E07C37D8D%40IBM1020C944423&forum_name=php-java-bridge-users
for details.
However, you should immediately see the bug by looking at the PHP
source code:
0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK
does NOT set errno (the result code is 0, not -1) so that errno
contains a bogus value, most likely the error code from a previously
failed sys call, so that
php_socket_errno() != EAGAIN
fails, depending on the application's PHP code, as errno sometimes
contains EAGAIN (from a previous poll()).
Just search the PHP sources for the pattern
} else if (php_pollfd_for(sock->socket, PHP_POLLREADABLE|POLLPRI, &tv)
>
0) {
if (0 == recv(sock->socket, &buf, sizeof(buf), MSG_PEEK) &&
php_socket_errno() != EAGAIN) {
alive = 0;
}
and set the errno or the lastErrorCode (for windows) to zero before
calling this pattern.
After that persistent sockets, soap and a few other places will work
reliably.
There are a few caveats, however. First, if you pass the last error
number to application-level, you might have to restore the last errno
immediately after the recv call. Second, I don't know what the
php_socket_errno() != EAGAIN should do, anyway, as EAGAIN is only set
when the previous sys call failed (result code -1, not 0!). So I suggest
to ask the author to explain his/her code before fixing anything.
Regards,
Jost Bökemeier
[2008-12-24 19:48:34] fel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2008-12-21 16:07:15] jost_boekemeier at users dot sf dot net
The relevant part of the bug trace was missing.
poll([{fd=16, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 1
([{fd=16, revents=POLLIN}])
recv(16, ""..., 1, MSG_PEEK)= 0
send(16, "PUT /JavaBridge/JavaBridge.phpjavabridge HTTP/1.1\r\nHost:
localhost\r\nContent-Length: 40\r\nX_JAVABRIDGE_CHANNEL:
/dev/shm/.php_java_bridgexN2WsO\r\n\r\n\177C"..., 185, 0) = 185
poll([{fd=16, events=POLLIN|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=16,
revents=POLLIN|POLLERR|POLLHUP}])
recv(16, ""..., 8192, 0)= 0
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/46917
--
Edit this bug report at http://bugs.php.net/?id=46917&edit=1
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: nelg at linuxsolutions dot co dot nz Reported By: iarenuno at eteo dot mondragon dot edu Status: Assigned Bug Type: LDAP related Operating System: * PHP Version: 5CVS, 6CVS (2008-11-01) Assigned To: pajoye New Comment: Hi, I am really keen to see this patch applied, as without it, the is some things that cannot easily be done in LDAP with PHP. Any progress? last comment seems to indicate it was going to be committed soon, but I don't see it in the php source tree yet. Previous Comments: [2008-11-16 23:22:00] iarenuno at eteo dot mondragon dot edu pajoye, thanks a lot for your work to get this patch into core. This was a much needed feature in big LDAP installations. Saludos. Iñaki. [2008-11-16 14:57:56] paj...@php.net Alexey has ported the patch to 5.3, it will committed in the next days. [2008-11-16 14:24:12] aklmnop at gmail dot com It would be great to have this essential paging functionality, and it's about time to update PHP's ldap. LDAP isn't going anywhere, and this has been waiting for long enough. Just because a myopic maintainer doesn't use LDAP doesn't mean it's not extremely widespread, urgent and important. Thanks. [2008-07-17 13:00:37] ando at sys-net dot it I didn't get any notification about this message, so I overlooked it; I was pointed here by a user (like many others) interested in the functionalities provided by the patch. In the meanwhile, I noticed that the code, after more than 2 years of inactivity, is now incompatible with the patch. Fixing it will require an amount of time that is incompatible with my current schedule. Feel free to fix it yourself. Cheers, p. [2008-06-05 19:10:08] paj...@php.net After a little discussions about windows with Howard, he pointed me to this bug report. It is now the right time to apply such patch (or any other new features) to ext/ldap as we are getting closer to the PHP 5.3 features freeze. Ando, do you have the time to work on it for php5.3? 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060&edit=1
#43506 [Com]: com_get_active_object always fails
ID: 43506
Comment by: gerrit at timingteam dot nl
Reported By: bvandermerwe at kbcat dot com
Status: Open
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
I experienced the same problem. Googling the internet I found a clue.
Somebody had a likewise problem. But he noticed that it only happened
when Apache was started as a service and not when Apache was started in
a console. I checked this in my situation. And indeed, all works fine
when you start Apache in a console. And you get the reported problem
when you start Apache as a service.
Hope this gives some clue to resolving the problem.
Greets, Gerrit.
Previous Comments:
[2008-11-06 11:46:02] tom dot neil dot bell at gmail dot com
Suffered this issue today trying enumerate a internet explorer
window. Turns out Internet Explorer doesn't register it self with the
"Running Object Table" so this function returns that error.
Work arounds are to either create a Browser Helper Object that will
add the IE instance to the ROT, or enumerate all windows via the
Shell.Application COM and iterate through them looking for
iexplore.exe .
Tom
[2007-12-05 18:14:58] bvandermerwe at kbcat dot com
Description:
com_get_active_object always returns "Operation Unavailable " even when
it should work for sure. Let me demonstrate:
Start up Microsoft Word (for example) on the server machine where
Apache and PHP are running. Then put the following text in a file called
x.vbs:
Dim app
Set app = GetObject(,"Word.Application")
if app is nothing then
wscript.echo "Got nothing"
else
wscript.echo "Got it!"
end if
Execute it by typing: cscript x.vbs.
Note that it works fine. Yet the following line in a PHP script always
returns "Operation Unavailable ":
$obj = com_get_active_object("Word.Application");
Using: $obj = new COM("Word.Application") works (meaning PHP COM is
working).
I just upgraded Apache to 2.2.6 and PHP 5.2.5 (using the Windows
installation executable binaries with pretty much default settings,
except PHP is in c:\PHP525 and I checked the options for MS and MYSQL
databases). Bugzilla and several PHP applications all work fine.
But it seems com_get_active_object *always* fails. I have Googled and I
can not find any examples of it out there or any security or other
settings related to it.
If it just calls GetObject, then how come calling GetObject from
VBScript works but in PHP does not? I did discover that some GetObject
calls are disabled under IIS for security reasons, but I am using Apache
and there is no reference to any setting that needs to be turned on
before this will work.
Reproduce code:
---
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml"; lang="en-US">
Test
Attempting to retrieve COM Object");
$obj = com_get_active_object("Word.Application"); //Fails!
if ($obj) {
echo("Object Found");
} else {
echo("Object NOT Found");
}
?>
Expected result:
No error. You should see:
Attempting to retrieve COM Object
Object Found
Actual result:
--
You see:
Attempting to retrieve COM Object
If PHP error tracing is enabled you also see:
Fatal error: Uncaught exception 'com_exception' with message 'Operation
unavailable ' in C:\ApacheDocumentRoot\test_com.php:10 Stack trace: #0
C:\ApacheDocumentRoot\test_com.php(10):
com_get_active_object('Word.Application') #1 {main} thrown in
C:\ApacheDocumentRoot\test_com.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=43506&edit=1
#46998 [NEW]: include inside include generates junk output
From: ian at ianhobson dot co dot uk Operating system: windows 2000 PHP version: 5.2.8 PHP Bug Type: *General Issues Bug description: include inside include generates junk output Description: include-ing a file that includes another file before producing any output, results in a few invalid characters being emitted before the line Reproduce code: --- Create a file with any trivial content. Include, require or require_once it from a second file. This second file needs the php tags and the include line only. Include this second file in a page like this (which is valid). http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> Test Demo Page This page has junk before the doctype Expected result: The source should start with the "<" of the doctype line as its first character. Actual result: -- In iIE source, you will see 6 squares before the http://bugs.php.net/?id=46998&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46998&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46998&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46998&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46998&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46998&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46998&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46998&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46998&r=support Expected behavior: http://bugs.php.net/fix.php?id=46998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46998&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46998&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46998&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46998&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46998&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46998&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46998&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46998&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46998&r=mysqlcfg
#46998 [Opn]: include inside include generates junk output
ID: 46998 User updated by: ian at ianhobson dot co dot uk Reported By: ian at ianhobson dot co dot uk Status: Open Bug Type: *General Issues Operating System: windows 2000 PHP Version: 5.2.8 New Comment: My server is set up to use utf8. I did not notice this problem when using Latin1. Previous Comments: [2009-01-03 23:43:26] ian at ianhobson dot co dot uk Description: include-ing a file that includes another file before producing any output, results in a few invalid characters being emitted before the line Reproduce code: --- Create a file with any trivial content. Include, require or require_once it from a second file. This second file needs the php tags and the include line only. Include this second file in a page like this (which is valid). http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> Test Demo Page This page has junk before the doctype Expected result: The source should start with the "<" of the doctype line as its first character. Actual result: -- In iIE source, you will see 6 squares before the http://bugs.php.net/?id=46998&edit=1
#46998 [Opn->Fbk]: include inside include generates junk output
ID: 46998 Updated by: j...@php.net Reported By: ian at ianhobson dot co dot uk -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: windows 2000 PHP Version: 5.2.8 New Comment: BOM? Previous Comments: [2009-01-03 23:44:54] ian at ianhobson dot co dot uk My server is set up to use utf8. I did not notice this problem when using Latin1. [2009-01-03 23:43:26] ian at ianhobson dot co dot uk Description: include-ing a file that includes another file before producing any output, results in a few invalid characters being emitted before the line Reproduce code: --- Create a file with any trivial content. Include, require or require_once it from a second file. This second file needs the php tags and the include line only. Include this second file in a page like this (which is valid). http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> Test Demo Page This page has junk before the doctype Expected result: The source should start with the "<" of the doctype line as its first character. Actual result: -- In iIE source, you will see 6 squares before the http://bugs.php.net/?id=46998&edit=1
