[PHP-BUG] Bug #54987 [NEW]: rmdir() does not clear statcache
From: Operating system: Windows 7 Pro 32-bit PHP version: 5.3.6 Package: Directory function related Bug Type: Bug Bug description:rmdir() does not clear statcache Description: See bug 43137. The same bug applies to Windows. Given a directory structure "C:\Test\Test2" with no files in either directory, rmdir("C:\Test\Test2") succeeds but subsequent rmdir("C:\Test") fails with "directory not empty", even though it is empty. Running clearstatcache() prior to rmdir("C:\Test") works around the problem. Test script: --- if (file_exists("C:\Test\Test2")) rmdir("C:\Test\Test2"); rmdir("C:\Test") Expected result: c:\Test\Test2 is deleted C:\Test is deleted No warnings Actual result: -- C:\Test\Test2 is deleted C:\Test is NOT deleted Receive warning that C:\Test is not empty -- Edit bug report at http://bugs.php.net/bug.php?id=54987&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54987&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54987&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54987&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54987&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54987&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54987&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54987&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54987&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54987&r=support Expected behavior: http://bugs.php.net/fix.php?id=54987&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54987&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54987&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54987&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54987&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54987&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54987&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54987&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54987&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54987&r=mysqlcfg
Bug #49521 [Csd->ReO]: PDO fetchObject sets values before calling constructor
Edit report at http://bugs.php.net/bug.php?id=49521&edit=1 ID: 49521 Updated by: da...@php.net Reported by: waps at pisem dot net Summary: PDO fetchObject sets values before calling constructor -Status: Closed +Status: Re-Opened Type: Bug Package: PDO related Operating System: Ubuntu 8.10 x64 PHP Version: 5.2.10 Assigned To: pierrick New Comment: According to the ML [1], Johannes, Felipe and Derick all agreed that this fix should be reverted, and instead the current behavior (values then constructor) should be properly documented. The desired behavior can be accomplished using the PDO::FETCH_PROPS_LATE option since 5.2.0. This means commit #290786 must be reverted in 5_2. It was already reverted in 5_3. (Commit #294903 [2]) [1] http://marc.info/?l=php-internals&m=126451457205904&w=2 [2] http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/pdo/pdo_stmt.c? r1=293036&r2=294903 Previous Comments: [2010-02-12 00:19:11] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=294942 Log: merge 290786: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2010-02-11 22:14:06] s...@php.net Automatic comment from SVN on behalf of johannes Revision: http://svn.php.net/viewvc/?view=revision&revision=294903 Log: Revert 290786: Fixed bug #49521 (PDO fetchObject sets values before calling constructor) [2009-11-15 16:23:41] fel...@php.net 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. Thanks for the patch. [2009-11-15 16:20:37] s...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=290786 Log: - Fixed bug #49521 (PDO fetchObject sets values before calling constructor) (patch by Pierrick) [2009-11-12 05:00:55] pierr...@php.net Patch available at: http://www.adoy.net/php/49521.PHP_5_2.patch http://www.adoy.net/php/49521.PHP_5_3.patch http://www.adoy.net/php/49521.PHP_6_0.patch 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=49521 -- Edit this bug report at http://bugs.php.net/bug.php?id=49521&edit=1
#161 [Csd]: ReadFile & File do not honour SAFE-MODE
ID: 161 Updated by: [EMAIL PROTECTED] Reported By: benkovsk at pha dot pvt dot cz Status: Closed -Bug Type: Other +Bug Type: *General Issues Operating System: Digital Unix v3.2D2 PHP Version: 3.0b5 Assigned To: rasmus New Comment: . Previous Comments: [1998-03-15 22:02:17] rasmus Fixed. Patch is available at: http://ca.php.net/cvsweb.cgi/fopen-wrappers.c?r1=1.14&r2=1.15 [1998-03-11 08:50:16] benkovsk at pha dot pvt dot cz Hi, I can read root owned files (/etc/passwd) with ReadFile() or File() even if phtml file and dir is owned by non-root user. phpinfo reports safemode=1. Include() in the same script on the same file returns permission error, which is right. BTW: Why there's not a Bug type 'Security'? My config line: ./configure --with-apache=../apache_1.3b5 --with-config-file-path=/usr/internet/apache/conf --disable-debug --enable -safe-mode --with-exec-dir=/usr/internet/apache/safe-bin --enable-memory-limit -- Edit this bug report at http://bugs.php.net/?id=161&edit=1
#33621 [Asn]: Exit code 0377 when calling a non-existant method using a dynamic call
ID: 33621 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned -Bug Type: Scripting Engine problem +Bug Type: Reproducible crash Operating System: Ubuntu Linux 5.04 PHP Version: 5CVS-2005-07-09 (dev) Assigned To: dmitry New Comment: After further testing, I have found two more cases where this error occurs: When __call is defined, but no args are specified (i.e. function __call() { }) and is_callable() or method_exists() are called, Exit Code 0377 is also given. Whilst I understand this is an erroneous situation, it should either not care (i.e. func_get_args is being used for some stupid reason) or throw an error. - Davey Previous Comments: [2005-07-09 05:17:59] [EMAIL PROTECTED] Description: I'm using head as of 5 minutes ago, approx: 23:10 EST Calling a non-existant method using the $obj->{$var}() notation causes an unexplained exit of the script with the exit code 0377. Reproduce code: --- {$var}(); } } $foo = new foo; ?> Expected result: Nothing Actual result: -- With --enable-debug all I get this from gdb: (gdb) run -f /var/www/php-cvs/testcase/evil_death_variable_method_call_nonexistant.php Starting program: /var/www/php-cvs/php-src/sapi/cli/php -f /var/www/php-cvs/testcase/evil_death_variable_method_call_nonexistant.php [Thread debugging using libthread_db enabled] [New Thread -1214975328 (LWP 9095)] Program exited with code 0377. -- Edit this bug report at http://bugs.php.net/?id=33621&edit=1
#29394 [Opn->Bgs]: Cant delete folder with name 2003
ID: 29394 Updated by: [EMAIL PROTECTED] Reported By: m at shnee dot com -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: winxp pro PHP Version: 4.3.7 New Comment: Tested in WinXP Home SP2, both functions work fine for me. - Davey Previous Comments: [2004-07-26 21:03:16] m at shnee dot com Description: Its funny, when a directory is named "2003", I am unable to rmdir or rename it. If I change the folder name (using windows explorer) to 2005, then I can run rmdir and rename with no problem. The return error is Permission Denied. But that isnt the issue as I can create a 2003 folder and 2005 folder at the same time, and I get the same problem. I can only edit/delete 2005, and 2003 always gives permission denied no matter what. I realize its possible this could be a windows issue. Just curious don't ya think? Reproduce code: --- rmdir("2003"); rename ("2003", "2002); Expected result: I expect it to delete/rename the directory. Actual result: -- Warning: rmdir(2003): Permission denied in C:\Documents and Settings\Mark\Desktop\www\new_pics\index.php on line 401 -- Edit this bug report at http://bugs.php.net/?id=29394&edit=1
#27709 [Bgs->Opn]: SimpleXML xpath function doesn't like default namespaces
ID: 27709 Updated by: [EMAIL PROTECTED] Reported By: fjortiz at comunet dot es -Status: Bogus +Status: Open Bug Type: SimpleXML related -Operating System: Windows 2000 Server +Operating System: Irrelevant -PHP Version: 5.0.0RC1 +PHP Version: 5.0RC3-dev -Assigned To: +Assigned To: rrichards New Comment: This *is* a bug, SimpleXML does not provide a registerNamespace() method like the DOM XPath implementation does. Without this, the XPath implementation in SimpleXML is crippled. So its half a bug, and half a feature request. This *needs* to be added before 5.0 final IMO The only way I can get this to workright now is: $xml =<< http://bar";> EOF; $simple_xml = simplexml_load_string($xml); // Add a namespace with the same URI as the default $simple_xml['xmlns:bar'] = "http://bar";; // Reload the XML so the namespace is recognised $simple_xml = simplexml_load_string($simple_xml->asXML()); - Davey Previous Comments: [2004-03-26 08:09:55] [EMAIL PROTECTED] 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 an XPath limitation. You need to use an expression like //*[local-name() = 'a'] or dont use default namespaces. [2004-03-26 04:51:30] fjortiz at comunet dot es Description: Hi, this example works with SimpleXML xpath: $string = << text stuff code XML; $xml = simplexml_load_string($string); $res = $xml->xpath('//a'); // returns array(1) But if we don't use a namespace prefix (default namespace), xpath, returns an empty array, array(0), for any xpath search: $string = << text stuff code XML; $xml = simplexml_load_string($string); $res = $xml->xpath('//a'); // returns array(0) This is a simple example, I found the problem with a bigger XML file (a WSDL file). This WSDL has 5 namespaces defined, and no problem at all with SimpleXML, as long as you don't define a default namespace... Thanks for your attention -- Edit this bug report at http://bugs.php.net/?id=27709&edit=1
#26662 [Opn]: Inconsistency in variable setting allows variables that start with numbers
ID: 26662 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4CVS-2003-12-18 (stable) New Comment: Both the FBSD and Win32 crashes are attributeable to the xdebug extension. Am filing a bug with the author on those. Please disregard those issues here. - Davey Previous Comments: [2003-12-18 21:51:46] [EMAIL PROTECTED] This is not a dup, as it is not fixed in PHP 5. Re-opening. [2003-12-18 21:42:28] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Dupe of bug #26601 which is marked won't fix. [2003-12-18 21:29:16] [EMAIL PROTECTED] Verified on PHP5b2, FreeBSD 4.4. PHP4 Snapshot on FreeBSD 4.4 yields this: [EMAIL PROTECTED]:~/php4-STABLE-200312190030/sapi/cli]$ ./php -r '${1} = "foo"; echo ${1}, "\n";' Segmentation fault (core dumped) Running the script on Win32 PHP4 snapshot (same one) gives an "Application Error". [2003-12-18 21:25:21] [EMAIL PROTECTED] Confirmed this bug is in PHP 5 B3RC1 as well. It gets worse, you can put whatever you want in ${} and it'll take it just fine... [2003-12-18 21:06:52] [EMAIL PROTECTED] Description: It is possible to set variables that start with numbers. I reproduced this with a PHP 4.3.x-dev snapshot AND PHP 5.0.0b2 (I was unable to get a snap to compile. autoconf errors out the wazoo). Reproduce code: --- [EMAIL PROTECTED] cli $ ./php -r '${1} = "foo"; echo ${1}, "\n";' foo Expected result: A parse error Actual result: -- Outputs 'foo' -- Edit this bug report at http://bugs.php.net/?id=26662&edit=1
#26662 [Ver]: Inconsistency in variable setting allows variables that start with numbers
ID: 26662 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4CVS-2003-12-18 (stable) New Comment: Verified on PHP5b2, FreeBSD 4.4. PHP4 Snapshot on FreeBSD 4.4 yields this: [EMAIL PROTECTED]:~/php4-STABLE-200312190030/sapi/cli]$ ./php -r '${1} = "foo"; echo ${1}, "\n";' Segmentation fault (core dumped) Running the script on Win32 PHP4 snapshot (same one) gives an "Application Error". Previous Comments: [2003-12-18 21:25:21] [EMAIL PROTECTED] Confirmed this bug is in PHP 5 B3RC1 as well. It gets worse, you can put whatever you want in ${} and it'll take it just fine... [2003-12-18 21:06:52] [EMAIL PROTECTED] Description: It is possible to set variables that start with numbers. I reproduced this with a PHP 4.3.x-dev snapshot AND PHP 5.0.0b2 (I was unable to get a snap to compile. autoconf errors out the wazoo). Reproduce code: --- [EMAIL PROTECTED] cli $ ./php -r '${1} = "foo"; echo ${1}, "\n";' foo Expected result: A parse error Actual result: -- Outputs 'foo' -- Edit this bug report at http://bugs.php.net/?id=26662&edit=1
#20208 [Opn->Bgs]: Wanted: a pearinfo() function analogous to phpinfo()
ID: 20208 Updated by: [EMAIL PROTECTED] Reported By: shiva at io dot com -Status: Open +Status: Bogus Bug Type:Feature/Change Request PHP Version: 4.2.3 New Comment: PEAR itself has a PEAR_Info package, please see: http://pear.php.net/pear_info to install: pear install PEAR_Info - Davey Previous Comments: [2002-11-01 01:32:58] shiva at io dot com I would like to see a pearinfo() function that looks like phpinfo(). The output would be grouped into three sections, based on the following PEAR commands: pear config-show pear list pear info The third section would feature the equivalent of "pear info " for each installed PEAR package. -- Edit this bug report at http://bugs.php.net/?id=20208&edit=1
#25676 [Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: WinXP/FreeBSD PHP Version: 4CVS-2003-09-26 (stable) New Comment: I can also confirm no hidden input element is output on Gentoo Linux using latest snapshot. Somethings *definately* wrong here, just need to figure out what. - Davey Previous Comments: [2003-09-27 10:23:59] [EMAIL PROTECTED] I've now had it confirmed on *two* Debian Linux boxes with a 20030927 snapshot that the hidden element does NOT get output. Trying to confirm on other distros, versions of windows and newer FBSD versions now. Note: the "Expected Result" has the extraneous hidden input, please mentally remove that ;) - Davey [2003-09-27 08:36:22] [EMAIL PROTECTED] RTFM "Note: If you want XHTML conformity, remove the form entry and use the tags around your form fields." [2003-09-26 23:20:55] [EMAIL PROTECTED] Description: Despite there being no form=fakeentry or form= (as I understand it, providing no value is the same as giving fakeentry) in url_rewriter.tags the form hidden element for the PHPSESSID is still output. I am trying to use form=action as the url_rewriter.tags and whilst this IS rewritten correctly, the hidden element is still being inserted. It seems that the fallback mechanism is faulty. This has been tested on several builds: PHP 4.3.3RC4 WinXP Latest Snapshot (200309270130) WinXP PHP 4.3.3 FreeBSD Latest Snapshot (200309270130) FreeBSD I have also had someone reporting the CORRECT behaviour on Debian with latest CVS so its quite the puzzle... - Davey Reproduce code: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled "; if(isset($_GET)) { var_dump($_GET); } ?> Foo: Bar: Expected result: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: Actual result: -- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: -- Edit this bug report at http://bugs.php.net/?id=25676&edit=1
#25676 [Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: WinXP/FreeBSD PHP Version: 4CVS-2003-09-26 (stable) New Comment: I've now had it confirmed on *two* Debian Linux boxes with a 20030927 snapshot that the hidden element does NOT get output. Trying to confirm on other distros, versions of windows and newer FBSD versions now. Note: the "Expected Result" has the extraneous hidden input, please mentally remove that ;) - Davey Previous Comments: [2003-09-27 08:36:22] [EMAIL PROTECTED] RTFM "Note: If you want XHTML conformity, remove the form entry and use the tags around your form fields." [2003-09-26 23:20:55] [EMAIL PROTECTED] Description: Despite there being no form=fakeentry or form= (as I understand it, providing no value is the same as giving fakeentry) in url_rewriter.tags the form hidden element for the PHPSESSID is still output. I am trying to use form=action as the url_rewriter.tags and whilst this IS rewritten correctly, the hidden element is still being inserted. It seems that the fallback mechanism is faulty. This has been tested on several builds: PHP 4.3.3RC4 WinXP Latest Snapshot (200309270130) WinXP PHP 4.3.3 FreeBSD Latest Snapshot (200309270130) FreeBSD I have also had someone reporting the CORRECT behaviour on Debian with latest CVS so its quite the puzzle... - Davey Reproduce code: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled "; if(isset($_GET)) { var_dump($_GET); } ?> Foo: Bar: Expected result: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: Actual result: -- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: -- Edit this bug report at http://bugs.php.net/?id=25676&edit=1
#25676 [Bgs->Opn]: Form hidden input ouput when any form=* is in url_rewriter.tags
ID: 25676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Session related Operating System: WinXP/FreeBSD PHP Version: 4CVS-2003-09-26 (stable) Previous Comments: [2003-09-27 08:36:22] [EMAIL PROTECTED] RTFM "Note: If you want XHTML conformity, remove the form entry and use the tags around your form fields." [2003-09-26 23:20:55] [EMAIL PROTECTED] Description: Despite there being no form=fakeentry or form= (as I understand it, providing no value is the same as giving fakeentry) in url_rewriter.tags the form hidden element for the PHPSESSID is still output. I am trying to use form=action as the url_rewriter.tags and whilst this IS rewritten correctly, the hidden element is still being inserted. It seems that the fallback mechanism is faulty. This has been tested on several builds: PHP 4.3.3RC4 WinXP Latest Snapshot (200309270130) WinXP PHP 4.3.3 FreeBSD Latest Snapshot (200309270130) FreeBSD I have also had someone reporting the CORRECT behaviour on Debian with latest CVS so its quite the puzzle... - Davey Reproduce code: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled "; if(isset($_GET)) { var_dump($_GET); } ?> Foo: Bar: Expected result: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: Actual result: -- http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> http://www.w3.org/1999/xhtml";> Untitled a=href,area=href,frame=src,input=src,form=action,foo=bararray(0) { } Foo: Bar: -- Edit this bug report at http://bugs.php.net/?id=25676&edit=1
#25176 [Opn->Bgs]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: Worked this one out... The reason is that the cgi binary has the php4ts.dll for PHP5 in its PWD, and when it requests the dll, thats where windows looks first and tells it that its there. The CLI binary does NOT have a php4ts.dll for PHP5 in its PWD, so windows traverses the %PATH%, where it finds the PHP4 php4ts.dll and tells the binary thats where it was found. Solution: Put a copy of php4ts.dll in c:\php5\cli if you need to run PHP5 and PHP4 simultaneously (testing), otherwise put c:\php5 in your path(note that when running the PHP4 binaries, they will find the PHP5 php4ts.dll, the problem is reversed). - Davey Previous Comments: [2003-08-20 18:56:58] [EMAIL PROTECTED] Note that this *only* happens with the CLI for me. So is there some difference in how this binary detects php4ts.dll to how the cgi one does? - Davey [2003-08-20 18:55:51] [EMAIL PROTECTED] OK, it seems that it finds my ZDE php4ts.dll in c:\program files\zend\bin is the one its finding (note that it didn't find the one in c:\program files\zend\bin) It errors with: "The procedure entry point zend_uv could not be located in the dynamic link library php4ts.dll" - presumably because that php4ts.dll is from 4.2.2 (IIRC). If I then restore my c:\php4\php4ts.dll is seems to find that one instead because the error goes back to the original one reported. Could this be %PATH% related? Or is PHP5 looking for php4ts.dll differently to PHP4? Note that PHP4 *also* finds the ZDE one (and errors with the same error) if c:\php4\php4ts.dll is not there. Something is going on here. - Davey [2003-08-20 18:50:16] [EMAIL PROTECTED] Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: "This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem." I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#25176 [Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: Note that this *only* happens with the CLI for me. So is there some difference in how this binary detects php4ts.dll to how the cgi one does? - Davey Previous Comments: [2003-08-20 18:55:51] [EMAIL PROTECTED] OK, it seems that it finds my ZDE php4ts.dll in c:\program files\zend\bin is the one its finding (note that it didn't find the one in c:\program files\zend\bin) It errors with: "The procedure entry point zend_uv could not be located in the dynamic link library php4ts.dll" - presumably because that php4ts.dll is from 4.2.2 (IIRC). If I then restore my c:\php4\php4ts.dll is seems to find that one instead because the error goes back to the original one reported. Could this be %PATH% related? Or is PHP5 looking for php4ts.dll differently to PHP4? Note that PHP4 *also* finds the ZDE one (and errors with the same error) if c:\php4\php4ts.dll is not there. Something is going on here. - Davey [2003-08-20 18:50:16] [EMAIL PROTECTED] Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: "This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem." I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. [2003-08-20 16:31:28] [EMAIL PROTECTED] I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#25176 [Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: OK, it seems that it finds my ZDE php4ts.dll in c:\program files\zend\bin is the one its finding (note that it didn't find the one in c:\program files\zend\bin) It errors with: "The procedure entry point zend_uv could not be located in the dynamic link library php4ts.dll" - presumably because that php4ts.dll is from 4.2.2 (IIRC). If I then restore my c:\php4\php4ts.dll is seems to find that one instead because the error goes back to the original one reported. Could this be %PATH% related? Or is PHP5 looking for php4ts.dll differently to PHP4? Note that PHP4 *also* finds the ZDE one (and errors with the same error) if c:\php4\php4ts.dll is not there. Something is going on here. - Davey Previous Comments: [2003-08-20 18:50:16] [EMAIL PROTECTED] Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: "This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem." I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. [2003-08-20 16:31:28] [EMAIL PROTECTED] I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew [2003-08-20 16:21:08] [EMAIL PROTECTED] Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#25176 [Bgs->Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Zend Engine 2 problem Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) Assigned To: zeev New Comment: Then there is something else at play here. I keep my PHP installs in seperate folders like this: c:\php4\ c:\php5\ I do not move php4ts.dll to system32 or anything, it should use the php4ts.dll in the c:\php*\ folder depending on which binary I run (PHP4 or PHP5). It appears that php5 is *not* using the php4ts.dll in c:\php5 (note the cli binary is in c:\php5\cli\php.exe) and indeed when I remove all other php4ts.dll's from my system I get: "This application has failed to start because php4ts.dll was not found. Re-installing the application may fix this problem." I am now going to check which php4ts.dll it is detecting (I have quite a few ;) and perhaps I can see why (i.e. if its the one from ZDE its most likely that that .dll is registered with the OS and the one with php5 is not, however PHP4 doesn't suffer from this, so something can be done to fix this) - Davey Previous Comments: [2003-08-20 18:12:54] [EMAIL PROTECTED] edink hit it on the head - it's not a bug, you're mixing binaries from different builds. In Windows there's a simple rule - if it builds, there are no missing symbols, they just can't exist. If there are missing symbols - the build would fail. The only situation where you can get missing symbols is if you mix different successfully-built binaries. [2003-08-20 17:55:04] [EMAIL PROTECTED] Zeev, you touched that stuff on 18th of August.. [2003-08-20 16:31:28] [EMAIL PROTECTED] I too also experienced this error in the php/php-cli dists. I also must note that the internal socket support throws a starnge error in the newer snaps as well. ~ Andrew [2003-08-20 16:21:08] [EMAIL PROTECTED] Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey [2003-08-20 07:59:04] [EMAIL PROTECTED] You mixed up .dlls from sever releases. Not a bug. 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/25176 -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#25176 [Bgs->Opn]: CLI Crashes with entry point not found in php4ts.dll
ID: 25176 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Reproducible crash Operating System: WinXP Pro SP1 PHP Version: 5CVS-2003-08-20 (dev) New Comment: Uhm... php4ts.dll is what is in the win32 PHP5 zip file, with a version of 5.0.0 - Davey Previous Comments: [2003-08-20 07:59:04] [EMAIL PROTECTED] You mixed up .dlls from sever releases. Not a bug. [2003-08-20 07:48:17] [EMAIL PROTECTED] Description: Running the CLI (with or without flags or input) always brings up the error: The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll. - Davey Reproduce code: --- C:\web\test>c:\php5\cli\php.exe -v [enter] [error] C:\web\test> Expected result: C:\web\test>c:\php5\cli\php.exe -v [enter] PHP 5.0.0b2-dev (cli) (built: Aug 20 2003 12:10:03) Copyright (c) 1997-2003 The PHP Group Zend Engine v2.0.0-dev, Copyright (c) 1998-2003 Zend Technologies C:\web\test> Actual result: -- Error message pops up with error "The procedure entry point _zend_hash_init could not be located in the dynamic link library php4ts.dll." -- Edit this bug report at http://bugs.php.net/?id=25176&edit=1
#22554 [NEW]: Show Source Anchors
From: davey at its-explosive dot net Operating system: n/a PHP version: 5CVS-2003-03-05 (dev) PHP Bug Type: Feature/Change Request Bug description: Show Source Anchors I think that a way to enhance PHP5 in the small area that is show_source() is not (just) to make it valid/cleaner HTML as has no doubht been requested before, but I would also like to see anchors placed in the document, to allow people to link to specific parts of their documents, the main one I can think of is namespace foo { } class foo { } and function foo { } - by being able to link to these specifically like: http://www.someurl.tld/source.phps#function_foo or #class_foo would make it easier to show specific parts of your code to people... Don't know what you think... just seems that some additional functionality in show_source()/phps could help collabaritive debugging such as over IRC or through forums... - Davey -- Edit bug report at http://bugs.php.net/?id=22554&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22554&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22554&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22554&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22554&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22554&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22554&r=support Expected behavior: http://bugs.php.net/fix.php?id=22554&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22554&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22554&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22554&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22554&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22554&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22554&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22554&r=gnused
#22176 [NEW]: Website Language Selection?
From: [EMAIL PROTECTED] Operating system: n/a PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: Website Language Selection? I was wondering if it'd be possible to make urls like this: http://www.php.net/manual/*/function.parse-ini-file.php and then when someone goes to that link, it displays a list of languages to choose from, then shows the file being requested in the chosen language... It will make linking to the manual much easier, especially on multi-lingual sites. Just a thought... not much work. - Davey -- Edit bug report at http://bugs.php.net/?id=22176&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22176&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22176&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22176&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22176&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22176&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22176&r=support Expected behavior: http://bugs.php.net/fix.php?id=22176&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22176&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22176&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22176&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22176&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22176&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22176&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22176&r=gnused
#20893 [Opn]: Strings as Arrays...
ID: 20893 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0RC2 New Comment: small code correction: $string = "foo"; foreach ($string as $i) { echo $i ."\n"; } Previous Comments: [2002-12-08 20:56:13] [EMAIL PROTECTED] This is probably a strange feature request, but I think it should be given a lot of thought, if it has not done so already. The request is this: strings should be treated as arrays of characters (which they are) when given as the arguement for functions which work on arrays. so for example: function foo ($chr) { echo $chr . "\n"; } $string = "bar"; array_walk($string,foo); would give the result: b a r Also, to be able to do this with strings: $string = "fo"; $string{} = "o"; so that $string == "foo" == TRUE Also, another thing that comes up often, is when trying to do this: $string = "foo"; foreach ($string as $i) { echo $string ."\n"; } does not work, and you have to do: $string = "foo"; for($i = 0;$i <= strlen($string);$i++) { echo $string{$i} ."\n"; } like I said, give this some thought, perhaps toss it around on php-dev etc.. - Davey -- Edit this bug report at http://bugs.php.net/?id=20893&edit=1
#20893 [NEW]: Strings as Arrays...
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0RC2 PHP Bug Type: Feature/Change Request Bug description: Strings as Arrays... This is probably a strange feature request, but I think it should be given a lot of thought, if it has not done so already. The request is this: strings should be treated as arrays of characters (which they are) when given as the arguement for functions which work on arrays. so for example: function foo ($chr) { echo $chr . "\n"; } $string = "bar"; array_walk($string,foo); would give the result: b a r Also, to be able to do this with strings: $string = "fo"; $string{} = "o"; so that $string == "foo" == TRUE Also, another thing that comes up often, is when trying to do this: $string = "foo"; foreach ($string as $i) { echo $string ."\n"; } does not work, and you have to do: $string = "foo"; for($i = 0;$i <= strlen($string);$i++) { echo $string{$i} ."\n"; } like I said, give this some thought, perhaps toss it around on php-dev etc.. - Davey -- Edit bug report at http://bugs.php.net/?id=20893&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20893&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20893&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20893&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20893&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20893&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20893&r=support Expected behavior: http://bugs.php.net/fix.php?id=20893&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20893&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20893&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20893&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20893&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20893&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20893&r=isapi
#20377 [WFx->Opn]: ini settings, per virtualhost
ID: 20377 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0-pre2 New Comment: /me points to php_admin_flag and php_admin_value - Davey Previous Comments: [2002-11-15 21:25:35] [EMAIL PROTECTED] ".htaccess also falls in the PERDIR class, and it's not a good idea to allow setting open_basedir and the other settings from this file especially for ISPs and stuff. --derick " [2002-11-11 20:15:05] [EMAIL PROTECTED] this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit this bug report at http://bugs.php.net/?id=20377&edit=1
#20377 [NEW]: ini settings, per virtualhost
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0-pre2 PHP Bug Type: Feature/Change Request Bug description: ini settings, per virtualhost this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit bug report at http://bugs.php.net/?id=20377&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20377&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20377&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20377&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20377&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20377&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20377&r=support Expected behavior: http://bugs.php.net/fix.php?id=20377&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20377&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20377&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20377&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20377&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20377&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20377&r=isapi
Bug #15667: problems with include()
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.4-RELEASE PHP version: 4.1.1 PHP Bug Type: Unknown/Other Function Bug description: problems with include() Whenever I include (or require) a page, using an http url as the file value (i.e. include("http://www.its-explosive.net/~davey/info.php";);) I get this header added to the top of the page I've included. This does not happen when I use a relative path. http://www.its-explosive.net/~davey/header.php show what happen when I include the file info.php using a http url to it. --- http://www.its-explosive.net/~davey/header.php";); ?> --- The contents of info.php are "". http://www.its-explosive.net/~davey/noheader.php shows what happens when I include it using the relative path: --- --- The only difference (in case you didn't go, or you missed it) is the text: --- X-Powered-By: PHP/4.1.1 Connection: close Content-Type: text/html --- is just added onto the top. If you goto the urls you will see my phpinfo(); and can perhaps glean some othre info from there. I do know that if someone else includes my PHP files in their website using the include("http://...";); code they also see the x-powered-by header... I've been looking around for a solution to this for weeks, I bet it's something simple, but I just can't find it. I hope you can help - Davey -- Edit bug report at http://bugs.php.net/?id=15667&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15667&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15667&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15667&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15667&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15667&r=support Expected behavior: http://bugs.php.net/fix.php?id=15667&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15667&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15667&r=submittedtwice