Bug #53820 [Opn]: segfault in libclntsh.so when using shared oci8 extension
Edit report at http://bugs.php.net/bug.php?id=53820&edit=1 ID: 53820 User updated by:wxianda at gmail dot com Reported by:wxianda at gmail dot com -Summary:segfault in liclntsh.so when using shared oci8 extension +Summary:segfault in libclntsh.so when using shared oci8 extension Status: Open Type: Bug Package:OCI8 related Operating System: Linux PHP Version:5.3.5 Block user comment: N Private report: N New Comment: sorry i type something wrong in the summary so i have to make an update Previous Comments: [2011-01-23 08:52:12] wxianda at gmail dot com Description: use the latest php 5.3.5, tested in: gcc 4.4.5, ubuntu 10.10 x86, oracle express; gcc ???, asia linux 2(same as RHEL5?) x86, oracle 10g R2; gcc ???, centos 4.5 x86, oracle 10g R1. ./configure --disable-all --disable-cgi --without-pear --with- oci8=shared,$ORACLE_HOME make php.ini: extension_dir = "./modules" extension = oci8.so oci8.privileged_connect = On environment variable ORACLE_HOME and ORACLE_SID are both correct. when using NULL as connection_string in oci_connect() to connect to oracle: sapi/cli/php -c php.ini -r "oci_internal_debug(TRUE); var_dump(oci_connect('sys', 'sys', NULL, NULL, OCI_SYSDBA));" it crashes: OCI8 DEBUG: OCIHandleAlloc at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1067) OCI8 DEBUG: OCIConnectionPoolCreate at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1068) OCI8 DEBUG: OCIConnectionPoolDestroy at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1069) OCI8 DEBUG: OCIHandleFree at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1070) OCI8 DEBUG: OCINlsEnvironmentVariableGet at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1826) OCI8 DEBUG L1: Got NO cached connection at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1871) OCI8 DEBUG: Bypassing client-side session pool for session create at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2833) OCI8 DEBUG: OCIEnvNlsCreate at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:2810) OCI8 DEBUG: OCIHandleAlloc at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2842) OCI8 DEBUG: OCIServerAttach at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:2850) Segmentation fault and the call stack shows that it crashes inside the libclntsh.so. But if I provide a value for connection_string in oci_connect(), it works fine, and the call stack in the libclntsh.so is different. And I try to build php using oci8 as a "static" extension(--oci8=$ORACLE_HOME), it also works fine when setting connection_string to NULL(this proves that my ORACLE_HOME and ORACLE_SID are correct). And I test this in the previous three platforms, it acts the same. And I also try to use the latest instant client 10 and 11, the same results come out. So I believe that it can be easily reproduced in most or all platforms. So is it the bug of php or oracle's client library??? -- Edit this bug report at http://bugs.php.net/bug.php?id=53820&edit=1
[PHP-BUG] Bug #53820 [NEW]: segfault in liclntsh.so when using shared oci8 extension
From: Operating system: Linux PHP version: 5.3.5 Package: OCI8 related Bug Type: Bug Bug description:segfault in liclntsh.so when using shared oci8 extension Description: use the latest php 5.3.5, tested in: gcc 4.4.5, ubuntu 10.10 x86, oracle express; gcc ???, asia linux 2(same as RHEL5?) x86, oracle 10g R2; gcc ???, centos 4.5 x86, oracle 10g R1. ./configure --disable-all --disable-cgi --without-pear --with- oci8=shared,$ORACLE_HOME make php.ini: extension_dir = "./modules" extension = oci8.so oci8.privileged_connect = On environment variable ORACLE_HOME and ORACLE_SID are both correct. when using NULL as connection_string in oci_connect() to connect to oracle: sapi/cli/php -c php.ini -r "oci_internal_debug(TRUE); var_dump(oci_connect('sys', 'sys', NULL, NULL, OCI_SYSDBA));" it crashes: OCI8 DEBUG: OCIHandleAlloc at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1067) OCI8 DEBUG: OCIConnectionPoolCreate at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1068) OCI8 DEBUG: OCIConnectionPoolDestroy at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1069) OCI8 DEBUG: OCIHandleFree at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:1070) OCI8 DEBUG: OCINlsEnvironmentVariableGet at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1826) OCI8 DEBUG L1: Got NO cached connection at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:1871) OCI8 DEBUG: Bypassing client-side session pool for session create at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2833) OCI8 DEBUG: OCIEnvNlsCreate at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:2810) OCI8 DEBUG: OCIHandleAlloc at (/home/xianda/php-5.3.5.orig/ext/oci8/oci8.c:2842) OCI8 DEBUG: OCIServerAttach at (/home/xianda/php- 5.3.5.orig/ext/oci8/oci8.c:2850) Segmentation fault and the call stack shows that it crashes inside the libclntsh.so. But if I provide a value for connection_string in oci_connect(), it works fine, and the call stack in the libclntsh.so is different. And I try to build php using oci8 as a "static" extension(--oci8=$ORACLE_HOME), it also works fine when setting connection_string to NULL(this proves that my ORACLE_HOME and ORACLE_SID are correct). And I test this in the previous three platforms, it acts the same. And I also try to use the latest instant client 10 and 11, the same results come out. So I believe that it can be easily reproduced in most or all platforms. So is it the bug of php or oracle's client library??? -- Edit bug report at http://bugs.php.net/bug.php?id=53820&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53820&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53820&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53820&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53820&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53820&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53820&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53820&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53820&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53820&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53820&r=support Expected behavior: http://bugs.php.net/fix.php?id=53820&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53820&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53820&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53820&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53820&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53820&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53820&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53820&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53820&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53820&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53820&r=mysqlcfg
Req #34570 [Opn]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570&edit=1 ID: 34570 Updated by: dtajchre...@php.net Reported by:steve-php-dev at spwiz dot com Summary:Implement some sort of setproctitle() in cli version Status: Open Type: Feature/Change Request -Package:Feature/Change Request +Package:*General Issues Operating System: Linux 2.4 kernel PHP Version:5.0.5 Block user comment: N Private report: N New Comment: http://pecl.php.net/package/proctitle Previous Comments: [2011-01-23 01:48:45] matt at mralston dot co dot uk I can't stress how much I'd like to see this feature implemented. I'm not a C programmer and I haven't got a clue how PHP is structured behind the scenes, but I can't imagine that this feature would be difficult to implement. I've been through a quite a journey with this conundrum today. I started out coding a new daemon this morning. Began to wish I could change the "/usr/bin/php ./caiman.php start" entry in the "ps auxw" listing this afternoon. I then spent some time researching how to do it (which was fustrating because I didn't even know how to phrase the question for Google when I started). I eventually found some C++ forums talking about modifying argv[0] and was excited and then disappointed when I found it didn't work in PHP. I drafted out a long e-mail I intended to send to the PHP developers, then figured I'd better properly RTFM and check out the bug tracker first. That's when I came across this feature request (and an older one from 2002). Unfortunately both appear to have stalled. So here I am, adding my voice to this request. I can grovel if you like! Please, please, please would somebody have a go at adding this feature when they've got some spare time? Even if the feature is ultimately rejected for inclusion into the trunk, a little patch that I could apply to my own servers would be appreciated so much. In the meantime, I'm just about to start poking around the PHP sources on my development box and see if I can implement something myself. As I said, I'm not a C programmer so I expect to struggle, but it's worth a shot. I'm thinking of something like: void pcntl_setproctitle(char *new_title) { sprintf(argv[0], new_title); } Thanks for listening to me ramble. - Matt [2005-09-20 23:39:12] steve-php-dev at spwiz dot com Description: I'm using the pcntl module in the CLI SAPI to fork off several processes. I'd like the processes to be able to identify themselves in ps. In Linux, you can do this by editing argv[0]. On BSD, you use the setproctitle() function. Other higher level languages support this feature. A simple perl script to do this on Linux would be: $0 = "bogus"; sleep 10; I tried modifying $argv[0], but that only modified the PHP scripts copy of argv, not the real argv. It'd be nice if there was a way to modify the process title directly. Ideally, it would be cross-platform (for Unix variants, at least). This was originally requested in 2002 (http://bugs.php.net/bug.php?id=18400), but was rejected. When using the pcntl functions in the CLI version, it really would be a useful feature. -- Edit this bug report at http://bugs.php.net/bug.php?id=34570&edit=1
Bug #49078 [Com]: Make Failed sapi/cli/php Error 1
Edit report at http://bugs.php.net/bug.php?id=49078&edit=1 ID: 49078 Comment by: de at engeljournal dot com Reported by:kdprice at baylou dot com Summary:Make Failed sapi/cli/php Error 1 Status: No Feedback Type: Bug Package:Compile Failure Operating System: CentOS 5 PHP Version:5.3SVN-2009-07-27 (snap) Block user comment: N Private report: N New Comment: I get the same problem. I start with ./configure --with-apxs2=/usr/local/apache2/bin/apxs --enable-sockets --enable- soap --with-gd --with-zlib --with-jpeg-dir=/usr --with-curl --with-png-dir=/usr --with-mysql=mysqlnd --with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd make && make install Expected result = success - Actual result ext/mysql/.libs/php_mysql.o: In function `_free_mysql_result': php_mysql.c:(.text+0x1c): undefined reference to `mysql_free_result' ext/mysql/.libs/php_mysql.o: In function `php_mysql_select_db': php_mysql.c:(.text+0xb8): undefined reference to `mysql_eof' php_mysql.c:(.text+0xe0): undefined reference to `mysql_fetch_row' php_mysql.c:(.text+0x10c): undefined reference to `mysql_select_db' ext/mysql/.libs/php_mysql.o: In function `_close_mysql_link': php_mysql.c:(.text+0x15b): undefined reference to `mysql_close' ext/mysql/.libs/php_mysql.o: In function `_close_mysql_plink': php_mysql.c:(.text+0x1bc): undefined reference to `mysql_close' ext/mysql/.libs/php_mysql.o: In function `zm_startup_mysql': php_mysql.c:(.text+0x45a): undefined reference to `mysql_server_init' ext/mysql/.libs/php_mysql.o: In function `zm_shutdown_mysql': php_mysql.c:(.text+0x486): undefined reference to `mysql_server_end' ext/mysql/.libs/php_mysql.o: In function `zm_info_mysql': php_mysql.c:(.text+0x5f2): undefined reference to `mysql_get_client_info' ext/mysql/.libs/php_mysql.o: In function `php_mysql_do_connect': php_mysql.c:(.text+0x725): undefined reference to `mysql_get_client_version' php_mysql.c:(.text+0x736): undefined reference to `mysql_get_client_version' php_mysql.c:(.text+0xcd0): undefined reference to `mysql_init' php_mysql.c:(.text+0xcff): undefined reference to `mysql_options' php_mysql.c:(.text+0xd46): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0xd73): undefined reference to `mysql_error' php_mysql.c:(.text+0xdb0): undefined reference to `mysql_errno' php_mysql.c:(.text+0xe10): undefined reference to `mysql_options' php_mysql.c:(.text+0xf4f): undefined reference to `mysql_ping' php_mysql.c:(.text+0xf63): undefined reference to `mysql_errno' php_mysql.c:(.text+0xfb5): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0x104d): undefined reference to `mysql_options' php_mysql.c:(.text+0x1254): undefined reference to `mysql_init' php_mysql.c:(.text+0x12fc): undefined reference to `mysql_options' php_mysql.c:(.text+0x1343): undefined reference to `mysql_real_connect' php_mysql.c:(.text+0x1370): undefined reference to `mysql_error' php_mysql.c:(.text+0x13ad): undefined reference to `mysql_errno' php_mysql.c:(.text+0x140d): undefined reference to `mysql_options' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_close': php_mysql.c:(.text+0x172a): undefined reference to `mysql_eof' php_mysql.c:(.text+0x1752): undefined reference to `mysql_fetch_row' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_client_info': php_mysql.c:(.text+0x194a): undefined reference to `mysql_get_client_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_host_info': php_mysql.c:(.text+0x1aad): undefined reference to `mysql_get_host_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_proto_info': php_mysql.c:(.text+0x1c15): undefined reference to `mysql_get_proto_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_get_server_info': php_mysql.c:(.text+0x1d2b): undefined reference to `mysql_get_server_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_info': php_mysql.c:(.text+0x1e8e): undefined reference to `mysql_info' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_thread_id': php_mysql.c:(.text+0x2017): undefined reference to `mysql_thread_id' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_stat': php_mysql.c:(.text+0x215e): undefined reference to `mysql_eof' php_mysql.c:(.text+0x2186): undefined reference to `mysql_fetch_row' php_mysql.c:(.text+0x21ae): undefined reference to `mysql_stat' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_client_encoding': php_mysql.c:(.text+0x2332): undefined reference to `mysql_character_set_name' ext/mysql/.libs/php_mysql.o: In function `zif_mysql_set_charset': php_mysql.c:(.text+0x24a1): undefined reference to `mysql_set_character_set' ext/mysql/.libs/php_mysql.o: In function `php_mysql_do_query_general': php_mysql.c:(.text+0x25b4): undefined reference to `mysql_eof' php_mysql.c:(.text+0x25dc): undefined reference to `mysql_fetch_row' php_mysql.c:(.tex
Req #34570 [Com]: Implement some sort of setproctitle() in cli version
Edit report at http://bugs.php.net/bug.php?id=34570&edit=1 ID: 34570 Comment by: matt at mralston dot co dot uk Reported by:steve-php-dev at spwiz dot com Summary:Implement some sort of setproctitle() in cli version Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Linux 2.4 kernel PHP Version:5.0.5 Block user comment: N Private report: N New Comment: I can't stress how much I'd like to see this feature implemented. I'm not a C programmer and I haven't got a clue how PHP is structured behind the scenes, but I can't imagine that this feature would be difficult to implement. I've been through a quite a journey with this conundrum today. I started out coding a new daemon this morning. Began to wish I could change the "/usr/bin/php ./caiman.php start" entry in the "ps auxw" listing this afternoon. I then spent some time researching how to do it (which was fustrating because I didn't even know how to phrase the question for Google when I started). I eventually found some C++ forums talking about modifying argv[0] and was excited and then disappointed when I found it didn't work in PHP. I drafted out a long e-mail I intended to send to the PHP developers, then figured I'd better properly RTFM and check out the bug tracker first. That's when I came across this feature request (and an older one from 2002). Unfortunately both appear to have stalled. So here I am, adding my voice to this request. I can grovel if you like! Please, please, please would somebody have a go at adding this feature when they've got some spare time? Even if the feature is ultimately rejected for inclusion into the trunk, a little patch that I could apply to my own servers would be appreciated so much. In the meantime, I'm just about to start poking around the PHP sources on my development box and see if I can implement something myself. As I said, I'm not a C programmer so I expect to struggle, but it's worth a shot. I'm thinking of something like: void pcntl_setproctitle(char *new_title) { sprintf(argv[0], new_title); } Thanks for listening to me ramble. - Matt Previous Comments: [2005-09-20 23:39:12] steve-php-dev at spwiz dot com Description: I'm using the pcntl module in the CLI SAPI to fork off several processes. I'd like the processes to be able to identify themselves in ps. In Linux, you can do this by editing argv[0]. On BSD, you use the setproctitle() function. Other higher level languages support this feature. A simple perl script to do this on Linux would be: $0 = "bogus"; sleep 10; I tried modifying $argv[0], but that only modified the PHP scripts copy of argv, not the real argv. It'd be nice if there was a way to modify the process title directly. Ideally, it would be cross-platform (for Unix variants, at least). This was originally requested in 2002 (http://bugs.php.net/bug.php?id=18400), but was rejected. When using the pcntl functions in the CLI version, it really would be a useful feature. -- Edit this bug report at http://bugs.php.net/bug.php?id=34570&edit=1
Bug #53815 [Opn->Bgs]: angela
Edit report at http://bugs.php.net/bug.php?id=53815&edit=1 ID: 53815 Updated by: dtajchre...@php.net Reported by:stellaangela at live dot it Summary:angela -Status: Open +Status: Bogus Type: Bug Package:ncurses related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-01-22 15:01:46] stellaangela at live dot it Description: --- >From manual page: http://www.php.net/function.mail#Description --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53815&edit=1
Bug #53814 [Opn->Bgs]: angela
Edit report at http://bugs.php.net/bug.php?id=53814&edit=1 ID: 53814 Updated by: dtajchre...@php.net Reported by:stellaangela at live dot it Summary:angela -Status: Open +Status: Bogus Type: Bug Package:ncurses related PHP Version:5.3.5 Block user comment: N Private report: N New Comment: . Previous Comments: [2011-01-22 15:01:44] stellaangela at live dot it Description: --- >From manual page: http://www.php.net/function.mail#Description --- -- Edit this bug report at http://bugs.php.net/bug.php?id=53814&edit=1
Bug #50675 [Com]: SoapClient can't handle object references correctly.
Edit report at http://bugs.php.net/bug.php?id=50675&edit=1 ID: 50675 Comment by: bulk at janoszen dot hu Reported by:margaritisz dot oresztesz at dotroll dot hu Summary:SoapClient can't handle object references correctly. Status: Open Type: Bug Package:SOAP related Operating System: Linux PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Confirmed in PHP 5.3.4, still the same bug. The only fix for us is porting the SOAP library from 5.2.0, which has other, more manageable bugs. Previous Comments: [2010-07-06 07:20:53] bulk at janoszen dot hu Is somebody looking into this? [2010-01-15 12:05:15] margaritisz dot oresztesz at dotroll dot hu Package on the previous link is damaged. Source code can be found at: http://code.dotroll.com/files/bugreports/php-50675-soaprefs/soap.tar.gz [2010-01-13 13:53:38] srina...@php.net the client.php that you attached is tar.gz of the same server side code. pl.attach / provide appropriate client reproduce code [2010-01-06 08:46:33] margaritisz dot oresztesz at dotroll dot hu Description: When sending the same object multiple times in a SOAP call, SoapClient replaces the object with a href='..' object reference. However the client generates the request envelope with an incorrect parameter name, so the server does not get the referenced object. Reproduce code: --- Sources of a simple server and client could be found at the following URL: http://charlie.extra.hu/php-soap/soap.tar.gz If I run client.php, it gets back an object filled with null parameters. It should recieve the first object sent to the server. If I change the reference's parameter name to 'secondUser', the SOAP response includes the correct object. Expected result: Expected the following soap envelope to be sent: 1 user Actual result: -- Got this request: 1 user -- Edit this bug report at http://bugs.php.net/bug.php?id=50675&edit=1
Bug #30034 [Com]: date('zS') does not always return the correct value
Edit report at http://bugs.php.net/bug.php?id=30034&edit=1 ID: 30034 Comment by: loveme99hebe at yahoo dot com dot tw Reported by:michael at michaelthompson dot org Summary:date('zS') does not always return the correct value Status: Bogus Type: Bug Package:Date/time related Operating System: * PHP Version:4.3.8 Block user comment: N Private report: N New Comment: home add:443-J JALAN SULTAN KG BARU 34000 TAIPING,PERAK,MALAYSIA I/C KAD:830617-08-6215 Previous Comments: [2004-09-09 08:09:57] der...@php.net But it's not a bug. The S parameter uses the current day-of-the month to generate the suffix (with the 'j' parameter), and not the day-of-the-year value. >From http://php.net/date: S English ordinal suffix for the day of the month, 2 charactersst, nd, rd or th. Works well with j [2004-09-09 08:08:00] der...@php.net Confirmed on Linux too, having a look now. [2004-09-09 06:37:17] michael at michaelthompson dot org Description: date('zS') does not return the correct value on/above(?) day 251 Reproduce code: --- date('zS'); # on (after ?) day 251 Expected result: 251st Actual result: -- 251th -- Edit this bug report at http://bugs.php.net/bug.php?id=30034&edit=1
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811&edit=1 ID: 53811 User updated by:jl_ewing at hotmail dot com Reported by:jl_ewing at hotmail dot com Summary:filesize disregards case sensitive file system Status: Wont fix Type: Bug Package:Filesystem function related Operating System: Windows XP PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I think you misunderstood. I was calling bull on the "highly experimental" statement. Microsoft fully supports the use the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive registry key and case sensitivity in the NTFS file system. In fact case sensitive file systems is a POSIX requirement. According to Microsoft: "POSIX requires a certain amount of functionality from the file system, such as the ability for a file to have more than one name (or hard links) and case-sensitive file naming. Neither FAT nor HPFS supports these features, which is another reason why a new file system was required for Windows NT. NTFS supports both hard links and case-sensitive naming. If you want to run in a POSIX-conforming environment, you need at least one NTFS disk partition on your computer." I don't recall stating anything about "all possible functions" and indeed a bulk of the applications (notepad, for example) and utilities do not understand what it means to have case sensitivity enabled or how that translates to the file system. Of course I wasn't asking Microsoft to fix that, I was only asking for PHP to be able to support what the underlying file system supports. If there are, in fact, separate API calls required to support reading/writing to case sensitive files then I understand the task and respectfully withdraw my request at this time. Previous Comments: [2011-01-22 18:22:22] paj...@php.net Yes, that's what I meant. Your statement about MSFT fully supporting it with all possible functions is wrong, btw. [2011-01-22 18:12:17] jl_ewing at hotmail dot com You mean case sensitive NTFS partition support is highly experimental? I'm calling bull on that as the feature has been around since at least 2005 and Microsoft FULLY supports it and if you were to search TechNet you would find many articles regarding the topic. [2011-01-22 13:16:28] paj...@php.net No, it should not. Case insensitive NTFS partition support is highly experimental and requires special cases and APIs calls. We aren't going to support that any time soon. [2011-01-22 06:19:02] jl_ewing at hotmail dot com Description: Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP file extracted \PHP535 directory HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive 0 C:\opt\files>dir Volume in drive C is Boot Volume Serial Number is 84D1-331E Directory of C:\opt\files 01/21/2011 11:03 PM . 01/21/2011 11:03 PM .. 01/21/2011 11:03 PM 3,400 testA.out 01/21/2011 11:03 PM 550 testa.out 2 File(s) 3,950 bytes 2 Dir(s) 65,225,863,168 bytes free C:\PHP535>php -f test.php (see test script) Array ( [testA.out] => 550 [testa.out] => 550 ) The file that was created first seems to be the one that it uses. On NTFS file systems that are case sensitive filesize should pick up the appropriate file sizes Test script: --- $dir = '\\opt\\files'; $index = array(); $files = scandir($dir); foreach ($files as $file) { if (is_file($dir . '\\' . $file)) { $sizeX = filesize($dir. "/$file"); $index[$file] = $sizeX; unset ($file, $sizeX); } } print_r($index); Expected result: Array ( [testA.out] => 3400 [testa.out] => 550 ) Actual result: -- Array ( [testA.out] => 550 [testa.out] => 550 ) -- Edit this bug report at http://bugs.php.net/bug.php?id=53811&edit=1
[PHP-BUG] Bug #53818 [NEW]: Missing info in pg_get_notify function
From: Operating system: Linux PHP version: 5.2.17 Package: PostgreSQL related Bug Type: Bug Bug description:Missing info in pg_get_notify function Description: Since Postgresql 9.0, event notifications fired by the NOTIFY sql command includes a payload (a 8000 bytes max piece of text). As of now, the PHP function pg_get_notify only retrieve the "channel" (name of the notification) and the backend pid. The attached patch improves this situation by adding the payload to the returned array of the pg_get_notify function, when the connected PG backend version is at least 9.0. Hope it helps... Test script: --- $dbconn = pg_connect(...) ; // To be completed pg_query($dbconn, "LISTEN toto"); pg_query($dbconn, "NOTIFY toto, 'Hello world !'"); $notify = pg_get_notify($dbconn, PGSQL_ASSOC) ; print_r($notify) ; Expected result: // Array("message" => "toto", "pid" => 12345, "payload" => "Hello world !") Actual result: -- // Array("message" => "toto", "pid" => 12345) -- Edit bug report at http://bugs.php.net/bug.php?id=53818&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53818&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53818&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53818&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53818&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53818&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53818&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53818&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53818&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53818&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53818&r=support Expected behavior: http://bugs.php.net/fix.php?id=53818&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53818&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53818&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53818&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53818&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53818&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53818&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53818&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53818&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53818&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53818&r=mysqlcfg
Bug #53817 [Bgs]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817&edit=1 ID: 53817 User updated by:jfha73 at gmail dot com Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I forgot to say, I also checked using php -m to check for missing dlls but it gave me no errors Previous Comments: [2011-01-22 19:00:00] jfha73 at gmail dot com I thought of that too, but all the DLLs are in place but when I check the error log for Apache it gives me the error I posted before. [2011-01-22 18:53:42] paj...@php.net Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817&edit=1
Bug #53817 [Com]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817&edit=1 ID: 53817 Comment by: jfha73 at gmail dot com Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: I thought of that too, but all the DLLs are in place but when I check the error log for Apache it gives me the error I posted before. Previous Comments: [2011-01-22 18:53:42] paj...@php.net Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817&edit=1
Bug #53816 [Opn->Bgs]: htmlspecialchars_decode() only works on lower case stuff
Edit report at http://bugs.php.net/bug.php?id=53816&edit=1 ID: 53816 Updated by: scott...@php.net Reported by:zelnaga at gmail dot com Summary:htmlspecialchars_decode() only works on lower case stuff -Status: Open +Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: entity names are case sensitive in the spec. Previous Comments: [2011-01-22 16:10:12] zelnaga at gmail dot com Description: htmlspecialchars_decode() and html_entity_decode() only convert lower case entities. eg. <, >, etc. Upper case entities - <, >, etc - are ignored. -- Edit this bug report at http://bugs.php.net/bug.php?id=53816&edit=1
Bug #53817 [Opn->Bgs]: Extensions not loading on 64-bit OS
Edit report at http://bugs.php.net/bug.php?id=53817&edit=1 ID: 53817 Updated by: paj...@php.net Reported by:jfha73 at gmail dot com Summary:Extensions not loading on 64-bit OS -Status: Open +Status: Bogus Type: Bug Package:*General Issues Operating System: Windows Server 2008 R2 PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Try in CLI and double read the error messages. You are certainly missing some DLLs in your PATH. Previous Comments: [2011-01-22 18:28:09] jfha73 at gmail dot com Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit this bug report at http://bugs.php.net/bug.php?id=53817&edit=1
[PHP-BUG] Bug #53817 [NEW]: Extensions not loading on 64-bit OS
From: Operating system: Windows Server 2008 R2 PHP version: 5.2.17 Package: *General Issues Bug Type: Bug Bug description:Extensions not loading on 64-bit OS Description: Hey guys, I have been trying to install PHP 5.2.17 and 5.3.5 to a 64-bit Windows Server 2008 R2 Using VC6 for Apache and VC9 for IIS and in both cases it fails to load extensions saying they are not win32 valid applications. Not all extensions have this problem, the ones I'm trying to load are: LDAP MySQL PDO_MySQL And a few others I don't remember, but those are the most important to my interests. The closest I got was a MySQLng extension loaded using 5.3.5, but the PHP application I'm using does not recognize this one as MySQL and I get stuck. I don't know if this will involve the refactor of the msi files to 64-bit installation files. I even tried using the ZIP files and even though it works better, it still doesn't load several extensions. Thanks for anything you can do about this. Expected result: Extensions to load on a 64-bit Windows Server 2008 R2 -- Edit bug report at http://bugs.php.net/bug.php?id=53817&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53817&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53817&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53817&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53817&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53817&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53817&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53817&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53817&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53817&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53817&r=support Expected behavior: http://bugs.php.net/fix.php?id=53817&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53817&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53817&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53817&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53817&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53817&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53817&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53817&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53817&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53817&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53817&r=mysqlcfg
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811&edit=1 ID: 53811 Updated by: paj...@php.net Reported by:jl_ewing at hotmail dot com Summary:filesize disregards case sensitive file system Status: Wont fix Type: Bug Package:Filesystem function related Operating System: Windows XP PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Yes, that's what I meant. Your statement about MSFT fully supporting it with all possible functions is wrong, btw. Previous Comments: [2011-01-22 18:12:17] jl_ewing at hotmail dot com You mean case sensitive NTFS partition support is highly experimental? I'm calling bull on that as the feature has been around since at least 2005 and Microsoft FULLY supports it and if you were to search TechNet you would find many articles regarding the topic. [2011-01-22 13:16:28] paj...@php.net No, it should not. Case insensitive NTFS partition support is highly experimental and requires special cases and APIs calls. We aren't going to support that any time soon. [2011-01-22 06:19:02] jl_ewing at hotmail dot com Description: Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP file extracted \PHP535 directory HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive 0 C:\opt\files>dir Volume in drive C is Boot Volume Serial Number is 84D1-331E Directory of C:\opt\files 01/21/2011 11:03 PM . 01/21/2011 11:03 PM .. 01/21/2011 11:03 PM 3,400 testA.out 01/21/2011 11:03 PM 550 testa.out 2 File(s) 3,950 bytes 2 Dir(s) 65,225,863,168 bytes free C:\PHP535>php -f test.php (see test script) Array ( [testA.out] => 550 [testa.out] => 550 ) The file that was created first seems to be the one that it uses. On NTFS file systems that are case sensitive filesize should pick up the appropriate file sizes Test script: --- $dir = '\\opt\\files'; $index = array(); $files = scandir($dir); foreach ($files as $file) { if (is_file($dir . '\\' . $file)) { $sizeX = filesize($dir. "/$file"); $index[$file] = $sizeX; unset ($file, $sizeX); } } print_r($index); Expected result: Array ( [testA.out] => 3400 [testa.out] => 550 ) Actual result: -- Array ( [testA.out] => 550 [testa.out] => 550 ) -- Edit this bug report at http://bugs.php.net/bug.php?id=53811&edit=1
Bug #53811 [Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811&edit=1 ID: 53811 User updated by:jl_ewing at hotmail dot com Reported by:jl_ewing at hotmail dot com Summary:filesize disregards case sensitive file system Status: Wont fix Type: Bug Package:Filesystem function related Operating System: Windows XP PHP Version:5.3.5 Block user comment: N Private report: N New Comment: You mean case sensitive NTFS partition support is highly experimental? I'm calling bull on that as the feature has been around since at least 2005 and Microsoft FULLY supports it and if you were to search TechNet you would find many articles regarding the topic. Previous Comments: [2011-01-22 13:16:28] paj...@php.net No, it should not. Case insensitive NTFS partition support is highly experimental and requires special cases and APIs calls. We aren't going to support that any time soon. [2011-01-22 06:19:02] jl_ewing at hotmail dot com Description: Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP file extracted \PHP535 directory HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive 0 C:\opt\files>dir Volume in drive C is Boot Volume Serial Number is 84D1-331E Directory of C:\opt\files 01/21/2011 11:03 PM . 01/21/2011 11:03 PM .. 01/21/2011 11:03 PM 3,400 testA.out 01/21/2011 11:03 PM 550 testa.out 2 File(s) 3,950 bytes 2 Dir(s) 65,225,863,168 bytes free C:\PHP535>php -f test.php (see test script) Array ( [testA.out] => 550 [testa.out] => 550 ) The file that was created first seems to be the one that it uses. On NTFS file systems that are case sensitive filesize should pick up the appropriate file sizes Test script: --- $dir = '\\opt\\files'; $index = array(); $files = scandir($dir); foreach ($files as $file) { if (is_file($dir . '\\' . $file)) { $sizeX = filesize($dir. "/$file"); $index[$file] = $sizeX; unset ($file, $sizeX); } } print_r($index); Expected result: Array ( [testA.out] => 3400 [testa.out] => 550 ) Actual result: -- Array ( [testA.out] => 550 [testa.out] => 550 ) -- Edit this bug report at http://bugs.php.net/bug.php?id=53811&edit=1
[PHP-BUG] Bug #53816 [NEW]: htmlspecialchars_decode() only works on lower case stuff
From: Operating system: Windows 7 PHP version: 5.3.5 Package: Unknown/Other Function Bug Type: Bug Bug description:htmlspecialchars_decode() only works on lower case stuff Description: htmlspecialchars_decode() and html_entity_decode() only convert lower case entities. eg. <, >, etc. Upper case entities - <, >, etc - are ignored. -- Edit bug report at http://bugs.php.net/bug.php?id=53816&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53816&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53816&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53816&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53816&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53816&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53816&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53816&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53816&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53816&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53816&r=support Expected behavior: http://bugs.php.net/fix.php?id=53816&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53816&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53816&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53816&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53816&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53816&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53816&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53816&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53816&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53816&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53816&r=mysqlcfg
[PHP-BUG] Bug #53815 [NEW]: angela
From: Operating system: PHP version: 5.3.5 Package: ncurses related Bug Type: Bug Bug description:angela Description: --- >From manual page: http://www.php.net/function.mail#Description --- -- Edit bug report at http://bugs.php.net/bug.php?id=53815&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53815&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53815&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53815&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53815&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53815&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53815&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53815&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53815&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53815&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53815&r=support Expected behavior: http://bugs.php.net/fix.php?id=53815&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53815&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53815&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53815&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53815&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53815&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53815&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53815&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53815&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53815&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53815&r=mysqlcfg
[PHP-BUG] Bug #53814 [NEW]: angela
From: Operating system: PHP version: 5.3.5 Package: ncurses related Bug Type: Bug Bug description:angela Description: --- >From manual page: http://www.php.net/function.mail#Description --- -- Edit bug report at http://bugs.php.net/bug.php?id=53814&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53814&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53814&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53814&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53814&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53814&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53814&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53814&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53814&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53814&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53814&r=support Expected behavior: http://bugs.php.net/fix.php?id=53814&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53814&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53814&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53814&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53814&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53814&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53814&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53814&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53814&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53814&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53814&r=mysqlcfg
Bug #53735 [Fbk->Opn]: NumberFormatter returns NaN when converting float point
Edit report at http://bugs.php.net/bug.php?id=53735&edit=1 ID: 53735 User updated by:mortenskyt at gmail dot com Reported by:mortenskyt at gmail dot com Summary:NumberFormatter returns NaN when converting float point -Status: Feedback +Status: Open Type: Bug Package:I18N and L10N related Operating System: MacOS X 10.6.6 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Hello again, On my Mac with PHP 5.3.5 from Macports: Internationalization support => enabled version => 1.1.0 ICU version => 4.6 (same version on non-working FreeBSD PHP 5.3.4-machine) The FreeBSD-machine with PHP 5.3.3, which works with no issues: Internationalization support => enabled version => 1.0.3 ICU version => 3.8.1 Previous Comments: [2011-01-22 08:41:40] s...@php.net Works for me in 5.3 on Mac OS X. Which ICU version do you have (check phpinfo())? [2011-01-13 14:46:59] mortenskyt at gmail dot com Description: In PHP 5.3.5, giving float point values to numfmt_format doesn't work when setlocale is set to a country using comma instead of dot in floating point. Also does not work in PHP 5.3.4 (FreeBSD) DOES work on 5.3.3 (FreeBSD) Perhaps interesting notes from my configuration: intl Internationalization support => enabled version => 1.1.0 ICU version => 4.6 Directive => Local Value => Master Value intl.default_locale => no value => no value intl.error_level => 0 => 0 Test script: --- http://bugs.php.net/bug.php?id=53735&edit=1
Req #53793 [Bgs]: ISAPI SUPPORT FOR PHP5.3
Edit report at http://bugs.php.net/bug.php?id=53793&edit=1 ID: 53793 Updated by: paj...@php.net Reported by:chutz747 at gmail dot com Summary:ISAPI SUPPORT FOR PHP5.3 Status: Bogus Type: Feature/Change Request Package:IIS related Operating System: Windows Server 2008 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: The delta you are describing tells me that your config is wrong. You also don't seem to use a opcode cache (try wincache). Have you tried to read the IIS documentation (iis.net or php's manual) to see how to configure it for good performence (or not too slow)? As ISAPI is technically faster than fastcgi, it is far from being stable (even if it works for you, it does not mean it is stable). Previous Comments: [2011-01-21 23:50:08] chut747 at gmail dot com thanks for your response. I have timed socalled fastCGI and Isapi, on 5 differnt servers under differing trafic conditions, including a dual-core, 2 quad-core, and 2 octo-core servers, under light, medium and heavy traffic conditions. Pageloads using ISAPI loaded in on average 2 - 3 secs, on fastCGI it took almost 8-10 secs. Same servers, different config. Ecomerce sites cannot use fastCGI it is just unaccaptable to their customers. PHP is a robust, wonderful, and easy to use language and I am glad to use it for my sites. Please compile an ISAPI module into an upcoming release, let developers choose which meathod they wan't instead of forcing them to use only one. [2011-01-20 05:35:00] ahar...@php.net ISAPI support was removed in PHP 5.3. As the migration guide says [0], the recommendation is to use FastCGI instead. [0] http://au2.php.net/manual/en/migration53.windows.php [2011-01-19 19:36:29] chutz747 at gmail dot com Description: I tried to download all of the zip and install files but can't find the php5isapi.dll file anywhere in PHP 3.5 version, did the extension change? is there any plan in compiling isapi support into 3.5. This is not so much a bug as it is necessary for certain sites. I am running a high-end ecomerce application that supports millions of daily users it runs just fine on a WIMP system with ISAPI with PHP 5.2. However if I try CGI or even Fast-CGI pages don't load fast enough. This is not a server ploblem this is a PHP problem which is why ISAPI support really needs to be added. I really would like to upgrade to 5.3 but without the ISAPI support I'm afraid I can never upgrade. All this talk about ISAPI being unstable in false. I have been running PHP5.2 on multiple servers all runing Windows and IIS for years via ISAPI and have never had a single failure or crash. It is super fast and super stable. Please complie a usable x86 windows build for PHP 5.3.5 with ISAPI. Thanks -- Edit this bug report at http://bugs.php.net/bug.php?id=53793&edit=1
Bug #53811 [Opn->Wfx]: filesize disregards case sensitive file system
Edit report at http://bugs.php.net/bug.php?id=53811&edit=1 ID: 53811 Updated by: paj...@php.net Reported by:jl_ewing at hotmail dot com Summary:filesize disregards case sensitive file system -Status: Open +Status: Wont fix Type: Bug Package:Filesystem function related Operating System: Windows XP PHP Version:5.3.5 Block user comment: N Private report: N New Comment: No, it should not. Case insensitive NTFS partition support is highly experimental and requires special cases and APIs calls. We aren't going to support that any time soon. Previous Comments: [2011-01-22 06:19:02] jl_ewing at hotmail dot com Description: Windows XP with NTFS and Case in-sensitivity is DISABLED (e.g. the file system is case sensitive). PHP 5.3.5 is VC6 x86 Non Thread Safe ZIP file extracted \PHP535 directory HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive 0 C:\opt\files>dir Volume in drive C is Boot Volume Serial Number is 84D1-331E Directory of C:\opt\files 01/21/2011 11:03 PM . 01/21/2011 11:03 PM .. 01/21/2011 11:03 PM 3,400 testA.out 01/21/2011 11:03 PM 550 testa.out 2 File(s) 3,950 bytes 2 Dir(s) 65,225,863,168 bytes free C:\PHP535>php -f test.php (see test script) Array ( [testA.out] => 550 [testa.out] => 550 ) The file that was created first seems to be the one that it uses. On NTFS file systems that are case sensitive filesize should pick up the appropriate file sizes Test script: --- $dir = '\\opt\\files'; $index = array(); $files = scandir($dir); foreach ($files as $file) { if (is_file($dir . '\\' . $file)) { $sizeX = filesize($dir. "/$file"); $index[$file] = $sizeX; unset ($file, $sizeX); } } print_r($index); Expected result: Array ( [testA.out] => 3400 [testa.out] => 550 ) Actual result: -- Array ( [testA.out] => 550 [testa.out] => 550 ) -- Edit this bug report at http://bugs.php.net/bug.php?id=53811&edit=1