Bug #65697 [Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697&edit=1
ID: 65697
User updated by:giunta dot gaetano at gmail dot com
Reported by:giunta dot gaetano at gmail dot com
Summary:is_link not working with windows junctions
Status: Not a bug
Type: Bug
Package:*Directory/Filesystem functions
Operating System: win7 64bit
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
Mmm, if it walks like a duck and quacks like a duck...
For all scenarios I can figure (backups, deploying code using symlinks),
treating a junction as a symlink makes more sense than not doing it.
Right now the only way to tell if a folder is actually a "real one" or not is
to use the array_diff trick I put in the test script. It looks hackish,
cumbersome, and why should lstat() treat a junction differently than is_link()
anyway?)
It is true that windows versions starting with Vista do create symlinks by
default, but tools like "Link Shell Extension" or the venerable sysinternals
junction.exe still allow one to create Junctions.
Previous Comments:
[2013-09-18 19:00:39] paj...@php.net
Junctions are not symlinks, the result is correct. Also the
junctions pointing to a directory may work. I remember
some windows version specific changes here, where it
ended as symlink or junction (recent always do it as
symlonk afair)
----
[2013-09-18 12:51:32] giunta dot gaetano at gmail dot com
Description:
is_link seems to return false for junction points which show up as
when using the DIR command.
It seems to work for junctions which show up as when using the DIR
command.
tested on php 5.3.27 and 5.4.14 (32 bit of course)
Test script:
---
linksource
07/09/2013 19:11 linktarget [D:\htdocs\linksource]
18/09/2013 14:30 linktarget2 [linksource]
Actual result:
--
D:\htdocs>php linktest.php
linksource
bool(false)
bool(true)
array(0) {
}
linktarget
bool(false)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
linktarget2
bool(true)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65697&edit=1
Bug #65697 [Nab]: is_link not working with windows junctions
Edit report at https://bugs.php.net/bug.php?id=65697&edit=1
ID: 65697
User updated by:giunta dot gaetano at gmail dot com
Reported by:giunta dot gaetano at gmail dot com
Summary:is_link not working with windows junctions
Status: Not a bug
Type: Bug
Package:*Directory/Filesystem functions
Operating System: win7 64bit
PHP Version:5.4.19
Block user comment: N
Private report: N
New Comment:
Ok, then be it
Previous Comments:
[2013-09-18 20:21:11] paj...@php.net
It is not about making sense or not. It is about backward compability and how
they
actually behave from a file system point of view.
Think of junction like hard links. You can't see hard link with is_link, no
matter
the platform.
[2013-09-18 20:13:02] giunta dot gaetano at gmail dot com
Mmm, if it walks like a duck and quacks like a duck...
For all scenarios I can figure (backups, deploying code using symlinks),
treating a junction as a symlink makes more sense than not doing it.
Right now the only way to tell if a folder is actually a "real one" or not is
to use the array_diff trick I put in the test script. It looks hackish,
cumbersome, and why should lstat() treat a junction differently than is_link()
anyway?)
It is true that windows versions starting with Vista do create symlinks by
default, but tools like "Link Shell Extension" or the venerable sysinternals
junction.exe still allow one to create Junctions.
[2013-09-18 19:00:39] paj...@php.net
Junctions are not symlinks, the result is correct. Also the
junctions pointing to a directory may work. I remember
some windows version specific changes here, where it
ended as symlink or junction (recent always do it as
symlonk afair)
----
[2013-09-18 12:51:32] giunta dot gaetano at gmail dot com
Description:
is_link seems to return false for junction points which show up as
when using the DIR command.
It seems to work for junctions which show up as when using the DIR
command.
tested on php 5.3.27 and 5.4.14 (32 bit of course)
Test script:
---
linksource
07/09/2013 19:11 linktarget [D:\htdocs\linksource]
18/09/2013 14:30 linktarget2 [linksource]
Actual result:
--
D:\htdocs>php linktest.php
linksource
bool(false)
bool(true)
array(0) {
}
linktarget
bool(false)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
linktarget2
bool(true)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=65697&edit=1
[PHP-BUG] Bug #65697 [NEW]: is_link not working with windows junctions
From: giunta dot gaetano at gmail dot com
Operating system: win7 64bit
PHP version: 5.4.19
Package: *Directory/Filesystem functions
Bug Type: Bug
Bug description:is_link not working with windows junctions
Description:
is_link seems to return false for junction points which show up as
when using the DIR command.
It seems to work for junctions which show up as when using the
DIR command.
tested on php 5.3.27 and 5.4.14 (32 bit of course)
Test script:
---
linksource
07/09/2013 19:11 linktarget [D:\htdocs\linksource]
18/09/2013 14:30 linktarget2 [linksource]
Actual result:
--
D:\htdocs>php linktest.php
linksource
bool(false)
bool(true)
array(0) {
}
linktarget
bool(false)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
linktarget2
bool(true)
bool(true)
array(8) {
[2]=>
int(16895)
[8]=>
int(1378562389)
[9]=>
int(1378562389)
[10]=>
int(1378562389)
["mode"]=>
int(16895)
["atime"]=>
int(1378562389)
["mtime"]=>
int(1378562389)
["ctime"]=>
int(1378562389)
}
--
Edit bug report at https://bugs.php.net/bug.php?id=65697&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65697&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65697&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65697&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65697&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65697&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65697&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65697&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65697&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65697&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65697&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65697&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65697&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65697&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65697&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65697&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65697&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65697&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65697&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65697&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65697&r=mysqlcfg
Bug #63413 [Com]: Intermittent warning and fatal error on require() statement
Edit report at https://bugs.php.net/bug.php?id=63413&edit=1 ID: 63413 Comment by: giunta dot gaetano at gmail dot com Reported by:ben at indietorrent dot org Summary:Intermittent warning and fatal error on require() statement Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:5.4.8 Block user comment: N Private report: N New Comment: Btw, did some testing on my rig: win7 64bit, apache 2.4.3/vc10 from Apache Lounge, php 5.3.20/vc9. Using the test scripts provided above, and "ab" hitting them 100 times in a row with concurrency ranging from 1 to 64. When no NTFS junctions in use => no sign of errors whatsoever When an NTFS junction in use => one or two php errors do happen, across the whole test (127k requests). NB: just accessing the main file over the junction is ok. The problems happen then the "require" call is for a file over in the junction-ed directory Previous Comments: ---- [2013-02-13 17:34:19] giunta dot gaetano at gmail dot com A behaviour which has been puzzling me and that might (or not) be related: we also have some failing code which assumes that filemtime should not be zero (for an existing file). This is generally happening on Linux servers at customers (php in mode_prefork), at times of high load, for nfs-mounted files [2012-11-16 16:29:11] ben at indietorrent dot org Additional testing indicates that this problem is likely related to a specific piece of software that has been installed on the affected machines, and not PHP or the manner in which it is integrated with Apache. I tested the steps-to-reproduce with the exact same project/code-base on a LAMP stack (Ubuntu 12.04 + Apache 2.2.22 + MySQL 5.5.24 + PHP 5.3.10) and cannot reproduce the issue, no matter how hard I hammer the server with requests. As mentioned previously, I am unable to reproduce this issue with a comparable stack on Mac OS 10.8, either. These facts pointed to a Windows-specific cause, perhaps related to Apache's "winnt" MPM, so I setup a VM with a pristine Windows 7 x86 installation. I installed the same stack components as are installed on the computers on which this issue occurs. Yet, after several hours of hammering the server with constant page-requests, not a single error has been registered in PHP's error log. If at any point I'm able to determine which software causes this issue, I will post my findings here. [2012-11-05 15:45:02] ben at indietorrent dot org Another update. I began to suspect that this is a thread-safety issue, so I downloaded the latest non-thread-safe version of PHP and configured Apache to serve PHP files via Fast-CGI (mod_fcgid). To my surprise, this problem still occurs, and it seems to be worse with Fast-CGI than with Mod-PHP. Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I hammered on Apache, these spurious require() failures did not occur. [2012-11-01 21:07:42] ben at indietorrent dot org It occurred to me to examine Apache's internal error log for entries that correspond to those in PHP's error log when this occurs. I noticed what may be an important clue. Sample entries in PHP's error log: --- [01-Nov-2012 13:29:41 America/New_York] PHP Warning: require(../include/global.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:41 America/New_York] PHP Fatal error: require(): Failed opening required '../include/global.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:43 America/New_York] PHP Warning: require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\include\global.inc.php on line 18 [01-Nov-2012 13:29:43 America/New_York] PHP Fatal error: require(): Failed opening required 'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\
Bug #63413 [Com]: Intermittent warning and fatal error on require() statement
Edit report at https://bugs.php.net/bug.php?id=63413&edit=1 ID: 63413 Comment by: giunta dot gaetano at gmail dot com Reported by:ben at indietorrent dot org Summary:Intermittent warning and fatal error on require() statement Status: Open Type: Bug Package:Scripting Engine problem Operating System: Windows 7 x64 PHP Version:5.4.8 Block user comment: N Private report: N New Comment: A behaviour which has been puzzling me and that might (or not) be related: we also have some failing code which assumes that filemtime should not be zero (for an existing file). This is generally happening on Linux servers at customers (php in mode_prefork), at times of high load, for nfs-mounted files Previous Comments: [2012-11-16 16:29:11] ben at indietorrent dot org Additional testing indicates that this problem is likely related to a specific piece of software that has been installed on the affected machines, and not PHP or the manner in which it is integrated with Apache. I tested the steps-to-reproduce with the exact same project/code-base on a LAMP stack (Ubuntu 12.04 + Apache 2.2.22 + MySQL 5.5.24 + PHP 5.3.10) and cannot reproduce the issue, no matter how hard I hammer the server with requests. As mentioned previously, I am unable to reproduce this issue with a comparable stack on Mac OS 10.8, either. These facts pointed to a Windows-specific cause, perhaps related to Apache's "winnt" MPM, so I setup a VM with a pristine Windows 7 x86 installation. I installed the same stack components as are installed on the computers on which this issue occurs. Yet, after several hours of hammering the server with constant page-requests, not a single error has been registered in PHP's error log. If at any point I'm able to determine which software causes this issue, I will post my findings here. [2012-11-05 15:45:02] ben at indietorrent dot org Another update. I began to suspect that this is a thread-safety issue, so I downloaded the latest non-thread-safe version of PHP and configured Apache to serve PHP files via Fast-CGI (mod_fcgid). To my surprise, this problem still occurs, and it seems to be worse with Fast-CGI than with Mod-PHP. Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I hammered on Apache, these spurious require() failures did not occur. [2012-11-01 21:07:42] ben at indietorrent dot org It occurred to me to examine Apache's internal error log for entries that correspond to those in PHP's error log when this occurs. I noticed what may be an important clue. Sample entries in PHP's error log: --- [01-Nov-2012 13:29:41 America/New_York] PHP Warning: require(../include/global.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:41 America/New_York] PHP Fatal error: require(): Failed opening required '../include/global.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\auxiliary\css.php on line 5 [01-Nov-2012 13:29:43 America/New_York] PHP Warning: require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): failed to open stream: No such file or directory in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\include\global.inc.php on line 18 [01-Nov-2012 13:29:43 America/New_York] PHP Fatal error: require(): Failed opening required 'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' (include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') in C:\Users\Ben\Documents\Projects\project Testing\project-svn\trunk\public\include\global.inc.php on line 18 --- Roughly-corresponding entries in Apache's error log: --- [Thu Nov 01 13:29:21.235844 2012] [core:error] [pid 6780:tid 1136] (OS 32)The process cannot access the file because it is being used by another process. : [client 10.0.1.57:65162] AH00127: Cannot map GET /project/public/js/jquery.accordion.js HTTP/1.1 to file, referer: https://ben-pc/project/public/company/history/ [Thu Nov 01 13:29:41.141441 2012] [core:error] [pid 6780:tid 1128] (OS 32)The process cannot access the file because it is being used by another process. : [client 10.0.1.57:65204] AH00127: Cannot map GET /project/public/common/js/libs
Bug #60976 [Com]: PHP crashes sometimes while parsing
Edit report at https://bugs.php.net/bug.php?id=60976&edit=1 ID: 60976 Comment by: giunta dot gaetano at gmail dot com Reported by:xrstf-misc at yahoo dot com Summary:PHP crashes sometimes while parsing Status: Open Type: Bug Package:Reproducible crash Operating System: Win7x64 PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I also have php crashes - win7 64, apache 2.2.21 from apache lounge. No error messages left in either php or apache logs - just a "server reset connection" error from the browser. The code ran fine up to php 5.3.8 (did not test with 539). It involves executing a custom page within eZPublish, it is hard for me to trace it to a single php file / command and attach it here... Previous Comments: [2012-02-05 15:19:32] xrstf-misc at yahoo dot com Here is the original file, wrapped in an 7z archive: http://www.xrstf.de/bug60976.7z (1KB) [2012-02-04 07:39:19] paj...@php.net Ah you already did. Which EOL do you use on your original script? Unix or windows ones? Maybe zip it and post a link to the zip file, so the contents won't be altered (lexer bug). [2012-02-04 07:37:39] paj...@php.net Please provide us the full script you use to reprodruce the crash. [2012-02-04 01:20:16] xrstf-misc at yahoo dot com Well this is the source file that caused the parse error: http://pastie.org/pastes/3312735/text (md5sum is 1bd8de828db862a5f118be4cc9773999, there are not trailing spaces and there is a blank line at the end of the file). I cannot give any shorter example. Sorry. [2012-02-04 00:43:41] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60976 -- Edit this bug report at https://bugs.php.net/bug.php?id=60976&edit=1
Bug #47122 [Com]: php5ts.dll crashes apache if mysql ext is used.
Edit report at http://bugs.php.net/bug.php?id=47122&edit=1 ID: 47122 Comment by: giunta dot gaetano at gmail dot com Reported by:Faither at web dot de Summary:php5ts.dll crashes apache if mysql ext is used. Status: Bogus Type: Bug Package:MySQL related Operating System: Windows + IE7 installs PHP Version:5.2.8 Block user comment: N New Comment: Re-reading pajoye's comment, I think I might have understood it. Translating for the layman: "remove the mysql bin dir from your path" Previous Comments: [2010-10-29 17:31:08] giunta dot gaetano at gmail dot com Not sure if it's the exact same bug, but this is happening to me too, with php 5.2.14. I tested using Apache 2.0.63, Apache 2.2.13 from ASF and 2.2.17 from ApacheLounge. Test application: eZ Publish 4.3. At first, Apache crashed using php_mysqli.dll, so I moved back to using mysql and disabled loading of mysqli. Now I got a crash in the main dll: Nom de lâapplication: Apache.exe Version de lâapplication: 2.0.63.200 Horodatage de l'application: 479031fa Nom du module par défaut:php5ts.dll Version du module par défaut:5.2.14.14 Horodateur du module par défaut: 4c47316f Code de lâexception:c005 Décalage de lâexception: ac5a Version du système: 6.0.6002.2.2.0.768.3 Identificateur de paramètres régionaux: 1036 Information supplémentaire n° 1: 1f17 Information supplémentaire n° 2: 97af06af30f0ff31d89de56503697f47 Information supplémentaire n° 3: 5dc0 Information supplémentaire n° 4: 94650c6b796579acf5df59b9b6b9dfd8 [2009-01-16 09:08:24] paj...@php.net Do not use libmysql 5.1 with PHP releases. [2009-01-16 03:07:23] Faither at web dot de Problem signature: Problem Event Name: APPCRASH Application Name: httpd.exe Application Version: 2.2.11.0 Application Timestamp:493f5d44 Fault Module Name:php5ts.dll Fault Module Version: 5.2.8.8 < (-; Fault Module Timestamp: 493d75fc Exception Code: c005 Exception Offset: ac5a OS Version: 6.0.6001.2.1.0.256.1 Locale ID:1031 Additional Information 1: 8932 Additional Information 2: bd08f61e9b0baa119ce3d8ab843a334c Additional Information 3: 15af Additional Information 4: 582f8703263a701737a9aefbdea6db5a [2009-01-16 02:54:18] Faither at web dot de Description: Apache/2.2.11 (Win32) (working if not used in conjuction with... mySql + PHP) Mysql Ver 14.14 Distrib 5.1.30, for Win32 (ia32) (working ... PHP 5.2.8 (working ...) Windowze Vizta OS Version 6.0.6001.2.1.0.256.1 And no problem with same setup running under Kubuntu 8.10; works like a charm - no errors(!!). While Googling my way through the internet i stumbled across this: "..." Dependency issue of php_mysql.dll: "..." failure in the dependencies. DwmAPI.dll. (Vista Window Manager) "..." from *http://techmale.com/2008/02/27/how-microsoft-caused-apache-php_mysqldll-to-failusing-vista-dwmapidll/ So the root of this problem seems to be an Internet Explorer dependency.(?) Reproduce code: --- http://bugs.php.net/bug.php?id=47122&edit=1
Bug #47122 [Com]: php5ts.dll crashes apache if mysql ext is used.
Edit report at http://bugs.php.net/bug.php?id=47122&edit=1 ID: 47122 Comment by: giunta dot gaetano at gmail dot com Reported by:Faither at web dot de Summary:php5ts.dll crashes apache if mysql ext is used. Status: Bogus Type: Bug Package:MySQL related Operating System: Windows + IE7 installs PHP Version:5.2.8 Block user comment: N New Comment: Not sure if it's the exact same bug, but this is happening to me too, with php 5.2.14. I tested using Apache 2.0.63, Apache 2.2.13 from ASF and 2.2.17 from ApacheLounge. Test application: eZ Publish 4.3. At first, Apache crashed using php_mysqli.dll, so I moved back to using mysql and disabled loading of mysqli. Now I got a crash in the main dll: Nom de lâapplication: Apache.exe Version de lâapplication: 2.0.63.200 Horodatage de l'application: 479031fa Nom du module par défaut:php5ts.dll Version du module par défaut:5.2.14.14 Horodateur du module par défaut: 4c47316f Code de lâexception:c005 Décalage de lâexception: ac5a Version du système: 6.0.6002.2.2.0.768.3 Identificateur de paramètres régionaux: 1036 Information supplémentaire n° 1: 1f17 Information supplémentaire n° 2: 97af06af30f0ff31d89de56503697f47 Information supplémentaire n° 3: 5dc0 Information supplémentaire n° 4: 94650c6b796579acf5df59b9b6b9dfd8 Previous Comments: [2009-01-16 09:08:24] paj...@php.net Do not use libmysql 5.1 with PHP releases. [2009-01-16 03:07:23] Faither at web dot de Problem signature: Problem Event Name: APPCRASH Application Name: httpd.exe Application Version: 2.2.11.0 Application Timestamp:493f5d44 Fault Module Name:php5ts.dll Fault Module Version: 5.2.8.8 < (-; Fault Module Timestamp: 493d75fc Exception Code: c005 Exception Offset: ac5a OS Version: 6.0.6001.2.1.0.256.1 Locale ID:1031 Additional Information 1: 8932 Additional Information 2: bd08f61e9b0baa119ce3d8ab843a334c Additional Information 3: 15af Additional Information 4: 582f8703263a701737a9aefbdea6db5a [2009-01-16 02:54:18] Faither at web dot de Description: Apache/2.2.11 (Win32) (working if not used in conjuction with... mySql + PHP) Mysql Ver 14.14 Distrib 5.1.30, for Win32 (ia32) (working ... PHP 5.2.8 (working ...) Windowze Vizta OS Version 6.0.6001.2.1.0.256.1 And no problem with same setup running under Kubuntu 8.10; works like a charm - no errors(!!). While Googling my way through the internet i stumbled across this: "..." Dependency issue of php_mysql.dll: "..." failure in the dependencies. DwmAPI.dll. (Vista Window Manager) "..." from *http://techmale.com/2008/02/27/how-microsoft-caused-apache-php_mysqldll-to-failusing-vista-dwmapidll/ So the root of this problem seems to be an Internet Explorer dependency.(?) Reproduce code: --- http://bugs.php.net/bug.php?id=47122&edit=1
#49622 [NEW]: allow usage of json and/or php standard serialize format for sessions
From: giunta dot gaetano at gmail dot com Operating system: !important PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: allow usage of json and/or php standard serialize format for sessions Description: The current session_decode() function is good when the user needs to decode a serialized session string, but it - needs to have session_start() called beforehand - has an impact on the current session state A lot of comments in the php man pages for unserialize() and session_decode() are from users trying to write a preg_ based decoder of session data (and failing). A new function that session_decode_to_array() that - returned the deserialized data as an array - did not impact current session state would imho be quite useful (or adding a flag param to the existing function, to the same effect) Since this feat. request has already been filed and closed as bogus (http://bugs.php.net/bug.php?id=42725), what I am proposing here is slightly different: besides 'wddx' and 'php', allow usage of 'json' and 'serialize' as native serialization formats for session data - the latter corresponding to the native serialize function. If there is some information loss involved in using those two formats (ie. references), just make it clear in the docs. -- Edit bug report at http://bugs.php.net/?id=49622&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49622&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49622&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49622&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49622&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49622&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49622&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49622&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49622&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49622&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49622&r=support Expected behavior: http://bugs.php.net/fix.php?id=49622&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49622&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49622&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49622&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49622&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49622&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49622&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49622&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49622&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49622&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49622&r=mysqlcfg
#47767 [Com]: include_once does not resolve windows symlinks or junctions
ID: 47767 Comment by: giunta dot gaetano at gmail dot com Reported By: lukemoynihan at gmail dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: win32 only - Windows Vista PHP Version: 5.2.9 Assigned To: pajoye New Comment: Besdides include/require, file_exist() calls also fail for files that are found in a dir that is a junction point Previous Comments: [2009-07-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-07-07 02:54:55] mario at unosquare dot com 5.3 does not support folder junctions. It used to be fine in 5.2.9-2 but now, with 5.3 it is not resolving the includes/requires. [2009-06-25 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-06-21 18:59:58] martin at curlybracket dot de I've tryed symlinked files and that is working for me, you're right. So, maybe the symlinked directory thing is another but related bug, right? I've also tryed the latest snapshot, but the problem is the same for me. [2009-06-17 19:37:30] paj...@php.net Does it work for you for symlinked files? Or does it fail too? 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/47767 -- Edit this bug report at http://bugs.php.net/?id=47767&edit=1
#48949 [Bgs]: max_execution_time from php.ini ignored
ID: 48949
User updated by: giunta dot gaetano at gmail dot com
Reported By: giunta dot gaetano at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: vista sp2
PHP Version: 5.3.0
New Comment:
ps: tested with the vc6 executable instead of the vc9 and it still
stops at 60 secs...
Previous Comments:
[2009-07-17 12:56:50] giunta dot gaetano at gmail dot com
here's the script to reproduce the test:
and here follows the output:
timeout: 300
0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
56. 57. 58. 59.
Fatal error: Maximum execution time of 60 seconds exceeded in
D:\htdocs\y.php on line 9
[2009-07-17 12:52:12] giunta dot gaetano at gmail dot com
Thanks for the tip, but I would not have opened the issue without
checking first phpinfo().
As stated in the initial report, even ini_get('max_execution_time')
reports the value of 300
[2009-07-17 12:41:51] j...@php.net
Your php.ini isn't loaded. Use phpinfo() output to figure out which one
is actually used. No bug here.
[2009-07-17 07:32:26] giunta dot gaetano at gmail dot com
max_execution_time=300 in php.ini (using apache sapi btw)
[2009-07-16 22:24:20] paj...@php.net
And what's the value set in php.ini?
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/48949
--
Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48949 [Bgs]: max_execution_time from php.ini ignored
ID: 48949
User updated by: giunta dot gaetano at gmail dot com
Reported By: giunta dot gaetano at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: vista sp2
PHP Version: 5.3.0
New Comment:
here's the script to reproduce the test:
and here follows the output:
timeout: 300
0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.
20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.
56. 57. 58. 59.
Fatal error: Maximum execution time of 60 seconds exceeded in
D:\htdocs\y.php on line 9
Previous Comments:
[2009-07-17 12:52:12] giunta dot gaetano at gmail dot com
Thanks for the tip, but I would not have opened the issue without
checking first phpinfo().
As stated in the initial report, even ini_get('max_execution_time')
reports the value of 300
[2009-07-17 12:41:51] j...@php.net
Your php.ini isn't loaded. Use phpinfo() output to figure out which one
is actually used. No bug here.
[2009-07-17 07:32:26] giunta dot gaetano at gmail dot com
max_execution_time=300 in php.ini (using apache sapi btw)
[2009-07-16 22:24:20] paj...@php.net
And what's the value set in php.ini?
----
[2009-07-16 22:17:27] giunta dot gaetano at gmail dot com
Description:
On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the
max_execution_time ini parameter is read correctly (as shown by
ini_get() and phpinfo()) but never used.
After 60 secs, the script times out with the message
"Fatal error: Maximum execution time of 60 seconds exceeded".
Adding a set_time_limit() or ini_set() call solves the problem.
--
Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48949 [Bgs]: max_execution_time from php.ini ignored
ID: 48949
User updated by: giunta dot gaetano at gmail dot com
Reported By: giunta dot gaetano at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: vista sp2
PHP Version: 5.3.0
New Comment:
Thanks for the tip, but I would not have opened the issue without
checking first phpinfo().
As stated in the initial report, even ini_get('max_execution_time')
reports the value of 300
Previous Comments:
[2009-07-17 12:41:51] j...@php.net
Your php.ini isn't loaded. Use phpinfo() output to figure out which one
is actually used. No bug here.
[2009-07-17 07:32:26] giunta dot gaetano at gmail dot com
max_execution_time=300 in php.ini (using apache sapi btw)
[2009-07-16 22:24:20] paj...@php.net
And what's the value set in php.ini?
[2009-07-16 22:17:27] giunta dot gaetano at gmail dot com
Description:
On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the
max_execution_time ini parameter is read correctly (as shown by
ini_get() and phpinfo()) but never used.
After 60 secs, the script times out with the message
"Fatal error: Maximum execution time of 60 seconds exceeded".
Adding a set_time_limit() or ini_set() call solves the problem.
--
Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48949 [Fbk->Opn]: max_execution_time from php.ini ignored
ID: 48949 User updated by: giunta dot gaetano at gmail dot com Reported By: giunta dot gaetano at gmail dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: vista sp2 PHP Version: 5.3.0 New Comment: max_execution_time=300 in php.ini (using apache sapi btw) Previous Comments: [2009-07-16 22:24:20] paj...@php.net And what's the value set in php.ini? [2009-07-16 22:17:27] giunta dot gaetano at gmail dot com Description: On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the max_execution_time ini parameter is read correctly (as shown by ini_get() and phpinfo()) but never used. After 60 secs, the script times out with the message "Fatal error: Maximum execution time of 60 seconds exceeded". Adding a set_time_limit() or ini_set() call solves the problem. -- Edit this bug report at http://bugs.php.net/?id=48949&edit=1
#48950 [NEW]: max_execution_time from php.ini ignored
From: giunta dot gaetano at gmail dot com Operating system: vista sp2 PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: max_execution_time from php.ini ignored Description: On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the max_execution_time ini parameter is read correctly (as shown by ini_get() and phpinfo()) but never used. After 60 secs, the script times out with the message "Fatal error: Maximum execution time of 60 seconds exceeded". Adding a set_time_limit() or ini_set() call solves the problem. -- Edit bug report at http://bugs.php.net/?id=48950&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48950&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48950&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48950&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48950&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48950&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48950&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48950&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48950&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48950&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48950&r=support Expected behavior: http://bugs.php.net/fix.php?id=48950&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48950&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48950&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48950&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48950&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48950&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48950&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48950&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48950&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48950&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48950&r=mysqlcfg
#48949 [NEW]: max_execution_time from php.ini ignored
From: giunta dot gaetano at gmail dot com Operating system: vista sp2 PHP version: 5.3.0 PHP Bug Type: *General Issues Bug description: max_execution_time from php.ini ignored Description: On windows vista, with apache 2.2.11, php 5.3.0 vc9 threadsafe, the max_execution_time ini parameter is read correctly (as shown by ini_get() and phpinfo()) but never used. After 60 secs, the script times out with the message "Fatal error: Maximum execution time of 60 seconds exceeded". Adding a set_time_limit() or ini_set() call solves the problem. -- Edit bug report at http://bugs.php.net/?id=48949&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48949&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48949&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48949&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48949&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48949&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48949&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48949&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48949&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48949&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48949&r=support Expected behavior: http://bugs.php.net/fix.php?id=48949&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48949&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48949&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48949&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48949&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48949&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48949&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48949&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48949&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48949&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48949&r=mysqlcfg
#48584 [NEW]: soapclient's option connection_timeout not respected while fetching wsdl
From: giunta dot gaetano at gmail dot com Operating system: winxp PHP version: 5.2.9 PHP Bug Type: SOAP related Bug description: soapclient's option connection_timeout not respected while fetching wsdl Description: The socket timeout option for soap clients is only respected when executing calls, but not when fetching the wsdl itself. This makes it quite hard to use remote wsdl files and provide to the end user an interface with a definite timeout (eg. 5 secs). Current code does not seem to use the timeout value in c function get_sdl in php_sdl.c Reproduce code: --- create a soap client pointing to a wsdl on an inexisting server set connection_timeout option to 5 in client constructor Expected result: error msg after 5 secs Actual result: -- error msg after 1 min -- Edit bug report at http://bugs.php.net/?id=48584&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48584&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48584&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48584&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48584&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48584&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48584&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48584&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48584&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48584&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48584&r=support Expected behavior: http://bugs.php.net/fix.php?id=48584&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48584&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48584&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48584&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48584&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48584&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48584&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48584&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48584&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48584&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48584&r=mysqlcfg
#42189 [Opn]: xmlrpc_set_type() crashes php
ID: 42189 User updated by: giunta dot gaetano at gmail dot com Reported By: giunta dot gaetano at gmail dot com Status: Open Bug Type: XMLRPC-EPI related Operating System: windows xp or 2000 PHP Version: 5.2.3 New Comment: I do not think it is going away anytime soon, as much as everybody could wish it, just because of the critical mass it has reached (kinda likle http and html...). It is widely used in blogging tools for trackbacks, by red hat for their rhn system update tool, and has a lot of libraries written in every conceivable language. Oh, and least I forget, it is also used by PEAR as THE distribution protocol, isn't it? Iirc breaking support for HTTP_RAW_MESSAGE (and hence pear xmlrpc) in php 5.2.2 caused quite an unpheaval in the user base... Otoh, xmlrpc might be dead and cold in the grave, it does not mean that a crasher bug has got to be left unpatched (imho, of course ;) Previous Comments: [2007-08-15 08:41:02] [EMAIL PROTECTED] To me it seems like xmlrpc is dead fish, I can't even access http://www.xmlrpc.com/ anymore. (dunno if it's temporary issue though) [2007-08-06 10:00:04] giunta dot gaetano at gmail dot com As a side note, mostly to comments on #22468 - the official epi lib has not seen any cvs commit in about 5 years, and the php engine is possibly the biggest user of the lib, so I would not mind too much forking the underlying codebase (bug #69492 was opened there after the php devs refused to fix 22468, but it's till open after 4,5 years...) [2007-08-02 20:56:37] giunta dot gaetano at gmail dot com Description: Trying to cast a non-iso8601 conforming string to an xmlrpc datetime object crashes php. This happens if the characters in position 0 to 6 are too high in the ascii table, presumably moving the converted date too far away in the future This is repro with php 447 and 523 Note that it 'might' be the same bug as #22468 (the cause looks the same allright), with the difference that you get corrupted data on gentoo, and a core dump on winblows... Reproduce code: --- Expected result: false Actual result: -- CRASH'N'BURN -- Edit this bug report at http://bugs.php.net/?id=42189&edit=1
#42189 [Opn]: xmlrpc_set_type() crashes php
ID: 42189 User updated by: giunta dot gaetano at gmail dot com Reported By: giunta dot gaetano at gmail dot com Status: Open Bug Type: XMLRPC-EPI related Operating System: windows xp or 2000 PHP Version: 5.2.3 New Comment: As a side note, mostly to comments on #22468 - the official epi lib has not seen any cvs commit in about 5 years, and the php engine is possibly the biggest user of the lib, so I would not mind too much forking the underlying codebase (bug #69492 was opened there after the php devs refused to fix 22468, but it's till open after 4,5 years...) Previous Comments: [2007-08-02 20:56:37] giunta dot gaetano at gmail dot com Description: Trying to cast a non-iso8601 conforming string to an xmlrpc datetime object crashes php. This happens if the characters in position 0 to 6 are too high in the ascii table, presumably moving the converted date too far away in the future This is repro with php 447 and 523 Note that it 'might' be the same bug as #22468 (the cause looks the same allright), with the difference that you get corrupted data on gentoo, and a core dump on winblows... Reproduce code: --- Expected result: false Actual result: -- CRASH'N'BURN -- Edit this bug report at http://bugs.php.net/?id=42189&edit=1
#42189 [NEW]: xmlrpc_set_type crashes php
From: giunta dot gaetano at gmail dot com Operating system: windows xp or 2000 PHP version: 5.2.3 PHP Bug Type: XMLRPC-EPI related Bug description: xmlrpc_set_type crashes php Description: Trying to cast a non-iso8601 conforming string to an xmlrpc datetime object crashes php. This happens if the characters in position 0 to 6 are too high in the ascii table, presumably moving the converted date too far away in the future This is repro with php 447 and 523 Note that it 'might' be the same bug as #22468 (the cause looks the same allright), with the difference that you get corrupted data on gentoo, and a core dump on winblows... Reproduce code: --- Expected result: false Actual result: -- CRASH'N'BURN -- Edit bug report at http://bugs.php.net/?id=42189&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42189&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42189&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42189&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42189&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42189&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42189&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42189&r=needscript Try newer version:http://bugs.php.net/fix.php?id=42189&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42189&r=support Expected behavior:http://bugs.php.net/fix.php?id=42189&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42189&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42189&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42189&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42189&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42189&r=dst IIS Stability:http://bugs.php.net/fix.php?id=42189&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42189&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42189&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42189&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42189&r=mysqlcfg
#40279 [Com]: fsockopen broken on IPv6
ID: 40279 Comment by: giunta dot gaetano at gmail dot com Reported By: SiliconFiend at gmail dot com Status: No Feedback Bug Type: Sockets related Operating System: Windows XP SP2 PHP Version: 5.2.0 New Comment: Very weird, this started happening to me, too. Symptoms: + ping 'localhost' returns ::1 + using "telnet localhost 80" works, ie apache responds ok + php fsockopen(localhost) stalls, plus apache show no access logs, nor etheral captures any packets on any nic How ipv6 got enabled is a mystery to me. It is explicitly disabled on ALL network connections I have in use. All I did today was enabling the wifi nic (intel 2200) to connect to my new home lan... Maybe the dns server is broadcasting ipv6 addresses for localhost (wtf) ??? I tried ipconfig /flushdns to no avail. No trace of ::1 in etc/hosts either... btw, ipconfig /displaydns shows: 5.64.3.10.in-addr.arpa Nome record . . . . . : 5.64.3.10.in-addr.arpa. Tipo record . . . . . : 12 Durata (TTL). . . . . : 0 Lunghezza dati. . . . : 4 Sezione . . . . . . . : Risposta Record PTR . . . . . : srvmappemxp 1.0.0.127.in-addr.arpa Nome record . . . . . : 1.0.0.127.in-addr.arpa. Tipo record . . . . . : 12 Durata (TTL). . . . . : 0 Lunghezza dati. . . . : 4 Sezione . . . . . . . : Risposta Record PTR . . . . . : localhost srvmappemxp Nome record . . . . . : srvmappemxp Tipo record . . . . . : 1 Durata (TTL). . . . . : 0 Lunghezza dati. . . . : 4 Sezione . . . . . . . : Risposta Record A (Host) . . . : 10.3.64.5 localhost Nome record . . . . . : localhost Tipo record . . . . . : 1 Durata (TTL). . . . . : 0 Lunghezza dati. . . . : 4 Sezione . . . . . . . : Risposta Record A (Host) . . . : 127.0.0.1 Previous Comments: [2007-03-14 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2007-02-17 17:31:21] SiliconFiend at gmail dot com I think I installed IPv6 on Windows using the "Install..."->Protocol function on the Properties window for my network connection. You can also open a command window and type "ipv6 install" to accomplish the same thing. Internet Explorer can't handle IPv6 literal addresses (such as [::1]) in the URL. See http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx Unfortunately, in an effort to work around this problem, I made some changes to my IPv6 configuration and now Apache is no longer binding to my IPv6 address, so I can't display a page even in Firefox right now. I'm trying to fix it. [2007-02-12 19:16:35] [EMAIL PROTECTED] How exactly did you enable IPv6 support in your Windows? >when http://[::1]/ is entered in Firefox, so Apache >is responding to IPv6 requests on port 80. Try using this address in telnet and MSIE. Do they work too? [2007-02-01 06:15:29] SiliconFiend at gmail dot com I should be more clear. Using php.ini-recommended suppressed the php warning/error output, but the error still occurred. [2007-01-30 18:33:49] SiliconFiend at gmail dot com Same result with the CVS snapshot. I tried both php.ini-dist and php.ini-recommended files for the php.ini. The only difference is that php.ini-recommended didn't display the errors. One note, though, probably unrelated--using the php5apache2.dll module file from this snapshot did not allow the server to start--nothing in the error log; it just immediately stopped after attempting to start it. I had been using the php5apache2.dll with the PHP version 5.2.0 distributed with XAMPP. This was the default configuration; I don't know why they didn't use 2_2. Anyway, changing the LoadModule directive to point to php5apache2_2.dll allowed the server to start. 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/40279 -- Edit this bug report at http://bugs.php.net/?id=40279&edit=1
