Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1 ID: 54128 Updated by: paj...@php.net Reported by:vavra at 602 dot cz Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package:Zip Related Operating System: Windows 2003 PHP Version:5.2.17 Assigned To:pajoye Block user comment: N Private report: N New Comment: zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). Previous Comments: [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_ has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. [2011-03-01 15:55:09] johan...@php.net I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as The stat() function obtains information about the file pointed to by path. Read, write, or execute permission of the named file is not required, but all directories listed in the path name leading to the file must be searchable. I assume it is similar on Windows. If the zip extension is accessing the temp dir this should probably be documented. Assigning to Pierre who knows zip and windows better :-) [2011-03-01 15:28:53] vavra at 602 dot cz Description: On Windows 2003, IIS we use php as CGI. The php process runs as a IUSR_ user. When we want to unzip a file, we get error 11 (ZIP_ER_OPEN). I tracked this by Process Monitor and I saw that ZipArchive::open() tries to list a directory. We use temp directory. On Windows 2003 it is C:\Windows\Temp. After listing this directory ZipArchive::open() returns 11. And doesn't continue at work. When I add right List Folder for user IUSR_ the open() call succeeds. I think it should be a kind of bug of c-runtime. I searched for ZIP_ER_OPEN in php source and this is returned nearly after calls of fopen() and stat(). It's odd that fopen() and stat() makes directory listing Test script: --- //without result testing: $zipfile = tempnam(sys_get_temp_dir(),'zip'); file_put_contents($zipfile, $a_zip_file_content); $zip = new ZipArchive(); $a_zip_file_content_reread = file_get_contents($zipfile, $a_zip_file_conent); //$a_zip_file_conent_reread has bean successfully read and has the same content as $a_zip_file_content $res=$zip-open($zipfile); if ($res!==true) echo Failed open a file: .$res; -- Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Req #40510 [Asn]: Add multicast support in sockets.c
Edit report at http://bugs.php.net/bug.php?id=40510edit=1 ID: 40510 Updated by: cataphr...@php.net Reported by:lew dot payne at gmail dot com Summary:Add multicast support in sockets.c Status: Assigned Type: Feature/Change Request Package:*General Issues Operating System: FreeBSD 6.2-REL PHP Version:5.2.1 Assigned To:cataphract Block user comment: N Private report: N New Comment: I understand you're frustrated with the lack of progress in this issue, but I assigned this to myself because I intend to implement this feature soon (read: in a matter of weeks, not years). Previous Comments: [2011-03-02 05:01:20] lew dot payne at gmail dot com This ticket was opened four years ago, at which time I supplied source code that I had modified to work on FreeBSD (the original only worked on Linux). If you want to seriously consider IPV6 support, please seriously consider finally integrating this patch, and then waiting another four years before considering IPV6. Yes, I'm being sarcastic... but with good reason. I was basically given the runaround, via email with whomever looks at these bug reports, to the point where I simply decided it's easier to *not* contribute anything. I find it both irritating and ironic that, four years later, there is yet another suggestion on delaying the commitment of this patch (e.g., IPV6). And you think government is discouraging and bureaucratic? [2011-02-27 17:15:53] cataphr...@php.net I think IPv6 support should be seriously considered before committing a multicast patch. [2011-02-27 09:48:11] paj...@php.net Please provide an updated patch and phpt against trunk [2009-12-29 15:30:05] pcdinh at gmail dot com Hi, Could someone take a look into this issue? Thanks Dinh [2007-03-07 13:41:17] daniel at rozsnyo dot com Hello, I've changed the patch to support the php-5.2.1 too. (this version appeared in my gentoo in these days..). It was just some and * shifted at arg4. Download from http://diary.rozsnyo.com/2006/06/16/php-multicast/ . The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=40510 -- Edit this bug report at http://bugs.php.net/bug.php?id=40510edit=1
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1 ID: 54128 User updated by:vavra at 602 dot cz Reported by:vavra at 602 dot cz Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package:Zip Related Operating System: Windows 2003 PHP Version:5.2.17 Assigned To:pajoye Block user comment: N Private report: N New Comment: The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn. Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right. Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird? Previous Comments: [2011-03-02 09:56:17] paj...@php.net zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_ has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. [2011-03-01 15:55:09] johan...@php.net I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as The stat() function obtains information about the file pointed to by path. Read, write, or execute permission of the named file is not required, but all directories listed in the path name leading to the file must be searchable. I assume it is similar on Windows. If the zip extension is accessing the temp dir this should probably be documented. Assigning to Pierre who knows zip and windows better :-) [2011-03-01 15:28:53] vavra at 602 dot cz Description: On Windows 2003, IIS we use php as CGI. The php process runs as a IUSR_ user. When we want to unzip a file, we get error 11 (ZIP_ER_OPEN). I tracked this by Process Monitor and I saw that ZipArchive::open() tries to list a directory. We use temp directory. On Windows 2003 it is C:\Windows\Temp. After listing this directory ZipArchive::open() returns 11. And doesn't continue at work. When I add right List Folder for user IUSR_ the open() call succeeds. I think it should be a kind of bug of c-runtime. I searched for ZIP_ER_OPEN in php source and this is returned nearly after calls of fopen() and stat(). It's odd that fopen() and stat() makes directory listing Test script: --- //without result testing: $zipfile = tempnam(sys_get_temp_dir(),'zip'); file_put_contents($zipfile, $a_zip_file_content); $zip = new ZipArchive(); $a_zip_file_content_reread = file_get_contents($zipfile, $a_zip_file_conent); //$a_zip_file_conent_reread has bean successfully read and has the same content as $a_zip_file_content $res=$zip-open($zipfile); if ($res!==true) echo Failed open a file: .$res; -- Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1 ID: 54128 Updated by: paj...@php.net Reported by:vavra at 602 dot cz Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package:Zip Related Operating System: Windows 2003 PHP Version:5.2.17 Assigned To:pajoye Block user comment: N Private report: N New Comment: The bug is a side effect of the permission issue. But we have (I repeat: we have) to do the existence check for the reason I explained earlier. I will see what can be done to still make it works but you better have to fix your perms instead. Previous Comments: [2011-03-02 10:44:59] vavra at 602 dot cz The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn. Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right. Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird? [2011-03-02 09:56:17] paj...@php.net zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_ has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. [2011-03-01 15:55:09] johan...@php.net I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as The stat() function obtains information about the file pointed to by path. Read, write, or execute permission of the named file is not required, but all directories listed in the path name leading to the file must be searchable. I assume it is similar on Windows. If the zip extension is accessing the temp dir this should probably be documented. Assigning to Pierre who knows zip and windows better :-) [2011-03-01 15:28:53] vavra at 602 dot cz Description: On Windows 2003, IIS we use php as CGI. The php process runs as a IUSR_ user. When we want to unzip a file, we get error 11 (ZIP_ER_OPEN). I tracked this by Process Monitor and I saw that ZipArchive::open() tries to list a directory. We use temp directory. On Windows 2003 it is C:\Windows\Temp. After listing this directory ZipArchive::open() returns 11. And doesn't continue at work. When I add right List Folder for user IUSR_ the open() call succeeds. I think it should be a kind of bug of c-runtime. I searched for ZIP_ER_OPEN in php source and this is returned nearly after calls of fopen() and stat(). It's odd that fopen() and stat() makes directory listing Test script: --- //without result testing: $zipfile = tempnam(sys_get_temp_dir(),'zip'); file_put_contents($zipfile, $a_zip_file_content); $zip = new ZipArchive(); $a_zip_file_content_reread = file_get_contents($zipfile, $a_zip_file_conent); //$a_zip_file_conent_reread has bean successfully read and has the same content as $a_zip_file_content $res=$zip-open($zipfile); if ($res!==true) echo Failed open a file: .$res; -- Edit this bug
[PHP-BUG] Bug #54133 [NEW]: Complex Object nested array problem
From: Operating system: Windows 7 PHP version: 5.3.5 Package: SOAP related Bug Type: Bug Bug description:Complex Object nested array problem Description: Hi, I am working with PHP as a SOAP Client and ASP.NET WCF as a Soap Server. The following is the Method Call and it's parameters: EditSelection (string apiKey, string SelectionID, long[] typeGroupIDs, long[] typeIDs, FilterNewData filter, long[] QueryIDs) The following is the FilterNewData Complex object: long[] CountriesIncludeIDs [get, set] long[] CountriesExcludeIDs [get, set] long[] CurrenciesIncludeIDs [get, set] long[] CurrenciesExcludeIDs [get, set] long[] AffiliatesIncludeIDs [get, set] long[] AffiliatesExcludeIDs [get, set] string Gender [get, set] int MinAge [get, set] int MaxAge [get, set] long[] RatingsIncludeIDs [get, set] long[] RatingsExcludeIDs [get, set] I noticed that if there is a complex object with arrays in it, it returns an Error Fetching http headers sometimes, and sometimes it doesn't. I have noticed that this error comes up when the data in the complex object is actually filled. If the object is passed without any data in the arrays, then it works, otherwise it doesn't. However, if the contents of the objects are exposed as normal parameters (all arrays in the object passed as method parameters), then it works fine. Expected result: Successfully send the data Actual result: -- Error Fetching http headers -- Edit bug report at http://bugs.php.net/bug.php?id=54133edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54133r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54133r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54133r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54133r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54133r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54133r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54133r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54133r=needscript Try newer version: http://bugs.php.net/fix.php?id=54133r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54133r=support Expected behavior: http://bugs.php.net/fix.php?id=54133r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54133r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54133r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54133r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54133r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54133r=dst IIS Stability: http://bugs.php.net/fix.php?id=54133r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54133r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54133r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54133r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54133r=mysqlcfg
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1 ID: 54128 User updated by:vavra at 602 dot cz Reported by:vavra at 602 dot cz Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package:Zip Related Operating System: Windows 2003 PHP Version:5.2.17 Assigned To:pajoye Block user comment: N Private report: N New Comment: The right permission for temp folder are default right permission for Windows Server systems. Microsoft probably has a security reason for not allowing IUSR_ user for listing a temp dir. Yes I can fix it by changing permissions or not using Windows Temp dir. I do not fordid you not testing file existence. I offer not do it by stat function ;-) Previous Comments: [2011-03-02 10:50:22] paj...@php.net The bug is a side effect of the permission issue. But we have (I repeat: we have) to do the existence check for the reason I explained earlier. I will see what can be done to still make it works but you better have to fix your perms instead. [2011-03-02 10:44:59] vavra at 602 dot cz The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn. Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right. Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird? [2011-03-02 09:56:17] paj...@php.net zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_ has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. [2011-03-01 15:55:09] johan...@php.net I assume this is expected bahvior. At least on UNIX/Linux systems stat is defined as The stat() function obtains information about the file pointed to by path. Read, write, or execute permission of the named file is not required, but all directories listed in the path name leading to the file must be searchable. I assume it is similar on Windows. If the zip extension is accessing the temp dir this should probably be documented. Assigning to Pierre who knows zip and windows better :-) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54128 -- Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Req #40510 [Com]: Add multicast support in sockets.c
Edit report at http://bugs.php.net/bug.php?id=40510edit=1 ID: 40510 Comment by: chrisw at networkm dot co dot uk Reported by:lew dot payne at gmail dot com Summary:Add multicast support in sockets.c Status: Assigned Type: Feature/Change Request Package:*General Issues Operating System: FreeBSD 6.2-REL PHP Version:5.2.1 Assigned To:cataphract Block user comment: N Private report: N New Comment: Judging by the amount of Google space taken up by people trying to do this (including myself) I am very much in favour of moving this issue forward ASAP. I also agree with the IPv6 support (to a point), but if this is to be added to PHP 5.2.x I would suggest it may not be necessary to implement at this stage. Moving forward, shouldn't we be encouraging the use of 5.3.x for new/upgrading users? In which case, I would suggest that adding full IPv6 support against 5.2 might be a waste of time - I would imagine there would be a lot of work involved in adding full IPv6 multicast/anycast support, whereas the existing supplied patch would presumably only require minor modifications to bring it into line with the current 5.2 releases. I am all in favour of fully supporting IPv6 in 5.3, but I also believe that in the interests of speed it would be useful to have this, simpler, IPv4 multicast support in 5.2. Maybe this would be considered an un-productive approach, but it's just a thought... Previous Comments: [2011-03-02 10:43:32] cataphr...@php.net I understand you're frustrated with the lack of progress in this issue, but I assigned this to myself because I intend to implement this feature soon (read: in a matter of weeks, not years). [2011-03-02 05:01:20] lew dot payne at gmail dot com This ticket was opened four years ago, at which time I supplied source code that I had modified to work on FreeBSD (the original only worked on Linux). If you want to seriously consider IPV6 support, please seriously consider finally integrating this patch, and then waiting another four years before considering IPV6. Yes, I'm being sarcastic... but with good reason. I was basically given the runaround, via email with whomever looks at these bug reports, to the point where I simply decided it's easier to *not* contribute anything. I find it both irritating and ironic that, four years later, there is yet another suggestion on delaying the commitment of this patch (e.g., IPV6). And you think government is discouraging and bureaucratic? [2011-02-27 17:15:53] cataphr...@php.net I think IPv6 support should be seriously considered before committing a multicast patch. [2011-02-27 09:48:11] paj...@php.net Please provide an updated patch and phpt against trunk [2009-12-29 15:30:05] pcdinh at gmail dot com Hi, Could someone take a look into this issue? Thanks Dinh The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=40510 -- Edit this bug report at http://bugs.php.net/bug.php?id=40510edit=1
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1 ID: 54128 Updated by: paj...@php.net Reported by:vavra at 602 dot cz Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file Status: Assigned Type: Bug Package:Zip Related Operating System: Windows 2003 PHP Version:5.2.17 Assigned To:pajoye Block user comment: N Private report: N New Comment: What I mean by alternative solutions. Just not sure now if it is worth it. Also sharing one temp for all vhost is not a wised idea :) Previous Comments: [2011-03-02 11:01:39] vavra at 602 dot cz The right permission for temp folder are default right permission for Windows Server systems. Microsoft probably has a security reason for not allowing IUSR_ user for listing a temp dir. Yes I can fix it by changing permissions or not using Windows Temp dir. I do not fordid you not testing file existence. I offer not do it by stat function ;-) [2011-03-02 10:50:22] paj...@php.net The bug is a side effect of the permission issue. But we have (I repeat: we have) to do the existence check for the reason I explained earlier. I will see what can be done to still make it works but you better have to fix your perms instead. [2011-03-02 10:44:59] vavra at 602 dot cz The function _zip_file_exists() is used only once in zip_open() after creating new or reading for open. The usage is not so universal. There is no need for testing of existence of file for which we have no read access. It's used in zip_open() and zip_open() reads or writes to a file. So you are testing existence of file and you have to have at least a read permission. So if you reimplement _zip_file_exists() with fopen you will not lose anything and users of ZipArchive will quite earn. Case where implementation of some file_exists() via fopen cannot be used is for example implementaion of tempnam - function which tries to generate unique file and can randomly generate some filename. There is a probability that filename exists and you have no read right. Again in zip_open() such universal behaviour of file_exists() function isn't required. So I thing you can reimplement it and you can spare a lot of time of ZipArchive users. See my test case: file_get_contents succeeded but ZipArchive:open not. Isn't it weird? [2011-03-02 09:56:17] paj...@php.net zip_file_exists is about testing the existence of a file so stat usage is perfectly valid in this case. We also have to test if the file exists, because of the options available on zip_open (create, overwrite, etc.). [2011-03-02 08:47:16] vavra at 602 dot cz Well, I've made another test. I've written a small c program compiled by VC9 containing calls of stat and fopen. In php I've called this program via exec(). When IUSR_ has no right to list the temp folder the result was: stat() failed with -1, fopen succeeded. So I think function _zip_file_exists() in zip/lib/zip_open.c should be rewritten. Instead of calling stat, it should be called fopen. Stat calls is made only for existence detection, no fields from struct stat are read. So you can replace stat without any limitations and users of ZipArchive::open will no longer be confused by behaviour of stat function. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=54128 -- Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
[PHP-BUG] Bug #54134 [NEW]: fputcsv $enclosure bug
From: Operating system: Windows 7 PHP version: 5.3SVN-2011-03-02 (snap) Package: *Directory/Filesystem functions Bug Type: Bug Bug description:fputcsv $enclosure bug Description: --- From manual page: http://www.php.net/function.fputcsv --- fputcsv($fh, array $line, ;, ''); this short samples provide us three double quotes (or none) around each elements of the array. Expected result: i expected one double quotes around each elements. Actual result: -- this short samples provide us three double quotes (or none) around each elements of the array. -- Edit bug report at http://bugs.php.net/bug.php?id=54134edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54134r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54134r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54134r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54134r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54134r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54134r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54134r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54134r=needscript Try newer version: http://bugs.php.net/fix.php?id=54134r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54134r=support Expected behavior: http://bugs.php.net/fix.php?id=54134r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54134r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54134r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54134r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54134r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54134r=dst IIS Stability: http://bugs.php.net/fix.php?id=54134r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54134r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54134r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54134r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54134r=mysqlcfg
Bug #54133 [Opn]: Complex Object nested array problem
Edit report at http://bugs.php.net/bug.php?id=54133edit=1 ID: 54133 User updated by:netfury87 at msn dot com Reported by:netfury87 at msn dot com Summary:Complex Object nested array problem Status: Open Type: Bug Package:SOAP related Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: I tried sending multiple ids (around 10) in all arrays and the same problem occured using no objects but all parameters are arrays. Previous Comments: [2011-03-02 10:56:27] netfury87 at msn dot com Description: Hi, I am working with PHP as a SOAP Client and ASP.NET WCF as a Soap Server. The following is the Method Call and it's parameters: EditSelection (string apiKey, string SelectionID, long[] typeGroupIDs, long[] typeIDs, FilterNewData filter, long[] QueryIDs) The following is the FilterNewData Complex object: long[] CountriesIncludeIDs [get, set] long[] CountriesExcludeIDs [get, set] long[] CurrenciesIncludeIDs [get, set] long[] CurrenciesExcludeIDs [get, set] long[] AffiliatesIncludeIDs [get, set] long[] AffiliatesExcludeIDs [get, set] string Gender [get, set] int MinAge [get, set] int MaxAge [get, set] long[] RatingsIncludeIDs [get, set] long[] RatingsExcludeIDs [get, set] I noticed that if there is a complex object with arrays in it, it returns an Error Fetching http headers sometimes, and sometimes it doesn't. I have noticed that this error comes up when the data in the complex object is actually filled. If the object is passed without any data in the arrays, then it works, otherwise it doesn't. However, if the contents of the objects are exposed as normal parameters (all arrays in the object passed as method parameters), then it works fine. Expected result: Successfully send the data Actual result: -- Error Fetching http headers -- Edit this bug report at http://bugs.php.net/bug.php?id=54133edit=1
Bug #53516 [Com]: open_basedir BUG introduced in PHP 5.2.15
Edit report at http://bugs.php.net/bug.php?id=53516edit=1
ID: 53516
Comment by: webmaster at imposit dot com
Reported by:ofi at evil dot net dot pl
Summary:open_basedir BUG introduced in PHP 5.2.15
Status: Closed
Type: Bug
Package:Streams related
Operating System: Linux 2.6.36.1
PHP Version:5.2.15
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
This seems not to be solved in 5.2.17 either
for example
open_basedir = /var/www
within /var/www/login.php has
include ('step2.php');
/var/www/step2.php exist (same right as other files, readable...)
openbasedir restriction denies access to the file
you need to include('./step2.php')
to get it work
this is not possible, on my hosts running tousands of different php
scripts
does work until and including version 5.2.14
Previous Comments:
[2010-12-15 14:50:48] joho at boojam dot se
Wouldn't this merit 5.2.16 considering it's quite fatal?
[2010-12-10 13:50:36] il...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2010-12-10 13:50:27] il...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=306184
Log: Fixed bug #53516 (Regression in open_basedir handling).
[2010-12-10 11:28:21] ofi at evil dot net dot pl
Description:
Just look at:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/main/fopen_wrappers.c?r1=303823r2=306136
and
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/main/fopen_wrappers.c?r1=305507r2=305698
'-1' is missing in 5_2 branch
Test script:
---
Not needed - just enable open_basedir.
Expected result:
Working php script.
Actual result:
--
Open_basedir restriction...
--
Edit this bug report at http://bugs.php.net/bug.php?id=53516edit=1
[PHP-BUG] Bug #54136 [NEW]: Secure SSL bind to Active Directory fails
From:
Operating system: Ubuntu 10.04 LTS
PHP version: 5.3.5
Package: LDAP related
Bug Type: Bug
Bug description:Secure SSL bind to Active Directory fails
Description:
Attempting to bind to server using SSL returns:
Warning: ldap_bind() Unable to bind to server: Can't contact LDAP server
while ldap_connect() returns success.
Using a non-encrypted channel works, and the server responds on ssl using
other libraries, including successful bind.
Test script:
---
?php
$username = 'username';
$password = 'password';
$account_suffix = '@example.com';
$hostnameSSL = 'ldaps://my.example.com:636';
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
// Attempting fix from http://www.php.net/manual/en/ref.ldap.php#77553
putenv('LDAPTLS_REQCERT=never');
# SSL bind attempt #
// Attempting syntax from
http://www.php.net/manual/en/function.ldap-bind.php#101445
$con = ldap_connect($hostnameSSL);
if (!is_resource($con)) trigger_error(Unable to connect to
$hostnameSSL,E_USER_WARNING);
// Options from http://www.php.net/manual/en/ref.ldap.php#73191
if (!ldap_set_option($con, LDAP_OPT_PROTOCOL_VERSION, 3))
{
trigger_error(Failed to set LDAP Protocol version to
3,E_USER_WARNING);
}
ldap_set_option($con, LDAP_OPT_REFERRALS, 0);
if (ldap_bind($con,$username . $account_suffix, $password)) die('All went
well using SSL');
ldap_close($con);
Expected result:
I expected ssl handshake, and secure bind.
E.G:
openssl s_client -connect my.example.com:636 -prexit
(...)
SSL handshake has read 5732 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher: RC4-MD5
Session-ID:
1B150642E45E5A37A76A804365F5DBB28F6597838808B603BE45A0525CBD
Session-ID-ctx:
Master-Key:
68F4DB2000D02CA5F19880DABE4602947C344C9E674A285DA3977F78F35610D46F1EA770D64F24D5C7DB5451FFB6895B
Key-Arg : None
Start Time: 1299071105
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Actual result:
--
ldap_create
ldap_url_parse_ext(ldaps://my.example.com:636)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP my.example.com:636
ldap_new_socket: 25
ldap_prepare_socket: 25
ldap_connect_to_host: Trying 1.1.1.1:636
ldap_pvt_connect: fd: 25 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ldap_result ld 0x22620e98 msgid 1
wait4msg ld 0x22620e98 msgid 1 (infinite timeout)
wait4msg continue ld 0x22620e98 msgid 1 all 1
** ld 0x22620e98 Connections:
* host: my.example.com port: 636 (default)
refcnt: 2 status: Connected
last used: Wed Mar 2 13:57:52 2011
** ld 0x22620e98 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x22620e98 request count 1 (abandoned 0)
** ld 0x22620e98 Response Queue:
Empty
ld 0x22620e98 response count 0
ldap_chkResponseList ld 0x22620e98 msgid 1 all 1
ldap_chkResponseList returns ld 0x22620e98 NULL
ldap_int_select
read1msg: ld 0x22620e98 msgid 1 all 1
ldap_err2string
[Wed Mar 02 13:57:52 2011] [error] [client ::1] PHP Warning: ldap_bind()
[a href='function.ldap-bind'function.ldap-bind/a]: Unable to bind to
server: Can't contact LDAP server in /public_html/test.php on line 28
[Wed Mar 02 13:57:52 2011] [error] [client ::1] PHP Stack trace:
[Wed Mar 02 13:57:52 2011] [error] [client ::1] PHP 1. {main}()
/public_html/test.php:0
[Wed Mar 02 13:57:52 2011] [error] [client ::1] PHP 2. ldap_bind()
/public_html/test.php:28
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
--
Edit bug report at http://bugs.php.net/bug.php?id=54136edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54136r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54136r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54136r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54136r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54136r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54136r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54136r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54136r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54136r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54136r=support
Expected behavior:
[PHP-BUG] Bug #54137 [NEW]: file_get_contents POST request sends additional line breaks
From:
Operating system: all
PHP version: 5.3.5
Package: Streams related
Bug Type: Bug
Bug description:file_get_contents POST request sends additional line breaks
Description:
When doing HTTP POST requests using file_get_contents and an appropriate
stream context (http method = POST, content = ...) two additional line
breaks (\r\n\r\n) are added below the POST message body. This is wrong
according to the default encoding application/x-www-form-urlencoded and
has been seen to upset some webservers (content length is incorrect).
Run the testscript and check the traffic using tcpdump/tcpflow or
wireshark. You'll see additional lines at the end of the message body.
Attached is a very simple patch against http_fopen_wrapper.c from PHP 5.3.5
source which removes sending \r\n\r\n.
Test script:
---
?php
$ctx = stream_context_create(array(
'http' = array(
'method' = 'POST',
'header' = 'Content-Type: application/x-www-form-urlencoded',
'content' = 'a=1b=2',
)
));
$response = file_get_contents('http://www.php.net/', false, $ctx);
echo $response;
--
Edit bug report at http://bugs.php.net/bug.php?id=54137edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54137r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54137r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54137r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54137r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54137r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54137r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54137r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54137r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54137r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54137r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54137r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54137r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54137r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54137r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54137r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54137r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54137r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54137r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54137r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54137r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54137r=mysqlcfg
[PHP-BUG] Bug #54138 [NEW]: DOMNode::getLineNo() doesn't return line number higher than 65535
From: Operating system: Windows 7 PHP version: 5.3.5 Package: XML Reader Bug Type: Bug Bug description:DOMNode::getLineNo() doesn't return line number higher than 65535 Description: DOMNode::getLineNo() doesn't return line number higher than 65535. I assume that unsigned short is used for file line enumeration either in XMLReader or DOMNode internals. Test script: --- Try reading with XMLReader an XML file that has more than 65535 lines. Then, when line nr. 65535 is reached, call XMLReader::expand()-getLineNo(). Expected result: Correct line number. Actual result: -- 65535 for lines, higher than 65525. -- Edit bug report at http://bugs.php.net/bug.php?id=54138edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54138r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54138r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54138r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54138r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54138r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54138r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54138r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54138r=needscript Try newer version: http://bugs.php.net/fix.php?id=54138r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54138r=support Expected behavior: http://bugs.php.net/fix.php?id=54138r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54138r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54138r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54138r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54138r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54138r=dst IIS Stability: http://bugs.php.net/fix.php?id=54138r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54138r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54138r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54138r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54138r=mysqlcfg
Bug #54128 [Com]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Comment by: carsten_sttgt at gmx dot de
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
PHP Version:5.2.17
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
Previous Comments:
[2011-03-02 11:08:58] paj...@php.net
What I mean by alternative solutions. Just not sure now if it is worth
it. Also
sharing one temp for all vhost is not a wised idea :)
[2011-03-02 11:01:39] vavra at 602 dot cz
The right permission for temp folder are default right permission for
Windows Server systems. Microsoft probably has a security reason for not
allowing IUSR_ user for listing a temp dir.
Yes I can fix it by changing permissions or not using Windows Temp dir.
I do not fordid you not testing file existence. I offer not do it by
stat function ;-)
[2011-03-02 10:50:22] paj...@php.net
The bug is a side effect of the permission issue. But we have (I repeat:
we have)
to do the existence check for the reason I explained earlier.
I will see what can be done to still make it works but you better have
to fix your
perms instead.
[2011-03-02 10:44:59] vavra at 602 dot cz
The function _zip_file_exists() is used only once in zip_open() after
creating new or reading for open. The usage is not so universal. There
is no need for testing of existence of file for which we have no read
access. It's used in zip_open() and zip_open() reads or writes to a
file. So you are testing existence of file and you have to have at least
a read permission. So if you reimplement _zip_file_exists() with fopen
you will not lose anything and users of ZipArchive will quite earn.
Case where implementation of some file_exists() via fopen cannot be used
is for example implementaion of tempnam - function which tries to
generate unique file and can randomly generate some filename. There is a
probability that filename exists and you have no read right.
Again in zip_open() such universal behaviour of file_exists() function
isn't required. So I thing you can reimplement it and you can spare a
lot of time of ZipArchive users. See my test case: file_get_contents
succeeded but ZipArchive:open not. Isn't it weird?
[2011-03-02 09:56:17] paj...@php.net
zip_file_exists is about testing the existence of a file so stat usage
is
perfectly valid in this case.
We also have to test if the file exists, because of the options
available on
zip_open (create, overwrite, etc.).
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
Bug #54138 [Opn-Bgs]: DOMNode::getLineNo() doesn't return line number higher than 65535
Edit report at http://bugs.php.net/bug.php?id=54138edit=1 ID: 54138 Updated by: rricha...@php.net Reported by:dmitrij at stepanov dot lv Summary:DOMNode::getLineNo() doesn't return line number higher than 65535 -Status: Open +Status: Bogus Type: Bug Package:XML Reader Operating System: Windows 7 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Known limitation of libxml2 Previous Comments: [2011-03-02 15:23:44] dmitrij at stepanov dot lv Description: DOMNode::getLineNo() doesn't return line number higher than 65535. I assume that unsigned short is used for file line enumeration either in XMLReader or DOMNode internals. Test script: --- Try reading with XMLReader an XML file that has more than 65535 lines. Then, when line nr. 65535 is reached, call XMLReader::expand()-getLineNo(). Expected result: Correct line number. Actual result: -- 65535 for lines, higher than 65525. -- Edit this bug report at http://bugs.php.net/bug.php?id=54138edit=1
Bug #54048 [Com]: unexpected strtotime() behavior with unix timestamps
Edit report at http://bugs.php.net/bug.php?id=54048edit=1
ID: 54048
Comment by: tomas dot brastavicius at quantum dot lt
Reported by:sheller0 at gmail dot com
Summary:unexpected strtotime() behavior with unix timestamps
Status: Open
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
If you want to pass a timestamp to strtotime() function you must prepend
the timestamp with '@' character. See
http://www.php.net/manual/en/datetime.formats.compound.php
Since you do not prepend '@' character, strtotime() assumes that you are
passing other than timestamp formatted string. For example, digits
1009584000 is interpreted as 10 hour 9 minutes 58 seconds, 4000 year.
Some function calls fails because no format matches given digits.
If you want to test a string against timestamp, you may use preg_match()
function.
Previous Comments:
[2011-02-18 20:30:02] sheller0 at gmail dot com
Description:
I'm working on a payment processor which unfortunately has to take
several types of date input, as a result I need to test if a date I'm
being passed is already a unix timestamp. For the most part strtotime()
will return false when passed a timestamp. There are a few edge cases
where it will return another timestamp sometime after year 2400 or
before 2000. If this is actually the expected behavior it might be
worthwhile to throw a warning in the documentation about passing
strtotime() unix timestamps
Test script:
---
$errors = 0;
$end_date = strtotime('January 1st 2020');
$start_date = strtotime('January 1st 2001');
$bad_years = array();
while ($start_date $end_date){
if (strtotime($start_date) !== false){
echo date ('Y-m-d', $start_date) . ' generates ' .
strtotime($start_date) . ' ' . date('Y-m-d', strtotime($start_date)) .
\n;
$bad_years[] = date('Y', strtotime($start_date));
$errors++;
}
$start_date += 86400;
}
print_r(array_unique($bad_years));
echo $errors errors generated\n;
Expected result:
sam.heller@sam:/var/www/development/api/app/scripts$ php test.php
Array
(
)
0 errors generated
sam.heller@sam:/var/www/development/api/app/scripts$
Actual result:
--
sam.heller@sam:/var/www/development/api/app/scripts$ php test.php
2001-09-14 generates 51442009244 3600-02-18
2001-09-15 generates -62163017947 -02-18
2001-09-25 generates 64064790099 4000-02-18
2001-09-26 generates -49540237092 0400-02-18
...
...
...
2019-05-22 generates -24294654070 1200-02-18
2019-05-23 generates 177669838738 7600-02-18
2019-06-02 generates -11671873215 1600-02-18
2019-06-03 generates 190292619593 8000-02-18
Array
(
[0] = 3600
[1] =
[2] = 4000
[3] = 0400
[4] = 6800
[5] = 0800
[6] = 7200
[8] = 1200
[9] = 7600
[11] = 8000
[12] = 4400
[14] = 8400
[15] = 4800
[17] = 5200
[18] = 1600
[20] = 2000
[22] = 2400
[23] = 8800
[25] = 9200
[26] = 5600
[28] = 9600
[29] = 6000
[31] = 6400
[32] = 2800
[34] = 3200
)
1007 errors generated
sam.heller@sam:/var/www/development/api/app/scripts$
--
Edit this bug report at http://bugs.php.net/bug.php?id=54048edit=1
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Updated by: paj...@php.net
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
-PHP Version:5.2.17
+PHP Version:5.3.5
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated?
Thanks.
The stat problem here is totally unrelated to realpath_r. There is a
reason why
we do it (see my other comment) and I already said that I have to see
what else
we can do to work around this problem without adding more platform
specific
changes in this implementation.
Previous Comments:
[2011-03-02 15:53:37] carsten_sttgt at gmx dot de
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
[2011-03-02 11:08:58] paj...@php.net
What I mean by alternative solutions. Just not sure now if it is worth
it. Also
sharing one temp for all vhost is not a wised idea :)
[2011-03-02 11:01:39] vavra at 602 dot cz
The right permission for temp folder are default right permission for
Windows Server systems. Microsoft probably has a security reason for not
allowing IUSR_ user for listing a temp dir.
Yes I can fix it by changing permissions or not using Windows Temp dir.
I do not fordid you not testing file existence. I offer not do it by
stat function ;-)
[2011-03-02 10:50:22] paj...@php.net
The bug is a side effect of the permission issue. But we have (I repeat:
we have)
to do the existence check for the reason I explained earlier.
I will see what can be done to still make it works but you better have
to fix your
perms instead.
[2011-03-02 10:44:59] vavra at 602 dot cz
The function _zip_file_exists() is used only once in zip_open() after
creating new or reading for open. The usage is not so universal. There
is no need for testing of existence of file for which we have no read
access. It's used in zip_open() and zip_open() reads or writes to a
file. So you are testing existence of file and you have to have at least
a read permission. So if you reimplement _zip_file_exists() with fopen
you will not lose anything and users of ZipArchive will quite earn.
Case where implementation of some file_exists() via fopen cannot be used
is for example implementaion of tempnam - function which tries to
generate unique file and can randomly generate some filename. There is a
probability that filename exists and you have no read right.
Again in zip_open() such universal behaviour of file_exists() function
isn't required. So I thing you can reimplement it and you can spare a
lot of time of ZipArchive users. See my test case: file_get_contents
succeeded but ZipArchive:open not. Isn't it weird?
Bug #54048 [Opn-Bgs]: unexpected strtotime() behavior with unix timestamps
Edit report at http://bugs.php.net/bug.php?id=54048edit=1
ID: 54048
Updated by: der...@php.net
Reported by:sheller0 at gmail dot com
Summary:unexpected strtotime() behavior with unix timestamps
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu 11.04
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2011-03-02 16:36:59] tomas dot brastavicius at quantum dot lt
If you want to pass a timestamp to strtotime() function you must prepend
the timestamp with '@' character. See
http://www.php.net/manual/en/datetime.formats.compound.php
Since you do not prepend '@' character, strtotime() assumes that you are
passing other than timestamp formatted string. For example, digits
1009584000 is interpreted as 10 hour 9 minutes 58 seconds, 4000 year.
Some function calls fails because no format matches given digits.
If you want to test a string against timestamp, you may use preg_match()
function.
[2011-02-18 20:30:02] sheller0 at gmail dot com
Description:
I'm working on a payment processor which unfortunately has to take
several types of date input, as a result I need to test if a date I'm
being passed is already a unix timestamp. For the most part strtotime()
will return false when passed a timestamp. There are a few edge cases
where it will return another timestamp sometime after year 2400 or
before 2000. If this is actually the expected behavior it might be
worthwhile to throw a warning in the documentation about passing
strtotime() unix timestamps
Test script:
---
$errors = 0;
$end_date = strtotime('January 1st 2020');
$start_date = strtotime('January 1st 2001');
$bad_years = array();
while ($start_date $end_date){
if (strtotime($start_date) !== false){
echo date ('Y-m-d', $start_date) . ' generates ' .
strtotime($start_date) . ' ' . date('Y-m-d', strtotime($start_date)) .
\n;
$bad_years[] = date('Y', strtotime($start_date));
$errors++;
}
$start_date += 86400;
}
print_r(array_unique($bad_years));
echo $errors errors generated\n;
Expected result:
sam.heller@sam:/var/www/development/api/app/scripts$ php test.php
Array
(
)
0 errors generated
sam.heller@sam:/var/www/development/api/app/scripts$
Actual result:
--
sam.heller@sam:/var/www/development/api/app/scripts$ php test.php
2001-09-14 generates 51442009244 3600-02-18
2001-09-15 generates -62163017947 -02-18
2001-09-25 generates 64064790099 4000-02-18
2001-09-26 generates -49540237092 0400-02-18
...
...
...
2019-05-22 generates -24294654070 1200-02-18
2019-05-23 generates 177669838738 7600-02-18
2019-06-02 generates -11671873215 1600-02-18
2019-06-03 generates 190292619593 8000-02-18
Array
(
[0] = 3600
[1] =
[2] = 4000
[3] = 0400
[4] = 6800
[5] = 0800
[6] = 7200
[8] = 1200
[9] = 7600
[11] = 8000
[12] = 4400
[14] = 8400
[15] = 4800
[17] = 5200
[18] = 1600
[20] = 2000
[22] = 2400
[23] = 8800
[25] = 9200
[26] = 5600
[28] = 9600
[29] = 6000
[31] = 6400
[32] = 2800
[34] = 3200
)
1007 errors generated
sam.heller@sam:/var/www/development/api/app/scripts$
--
Edit this bug report at http://bugs.php.net/bug.php?id=54048edit=1
[PHP-BUG] Bug #54140 [NEW]: array_merge() break keys during merge
From:
Operating system:
PHP version: 5.3.5
Package: Arrays related
Bug Type: Bug
Bug description:array_merge() break keys during merge
Description:
array_merge interprets string keys, containing only digits as numeric keys,
if numeric overflow not reached.
String keys should works as strings regarless of their contents.
Test script:
---
var_dump(array_merge(array('t777'= array(I'm a string;
var_dump(array_merge(array(42424242= array(I'm a string of
digits;
var_dump(array_merge(array(7=
array(I'm string of digits too;
var_dump(is_string(42424242));
var_dump(is_string(42424242));
var_dump(is_string(7));
Expected result:
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[42424242]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
Actual result:
--
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[0]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
--
Edit bug report at http://bugs.php.net/bug.php?id=54140edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54140r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54140r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54140r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54140r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54140r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54140r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54140r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54140r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54140r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54140r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54140r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54140r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54140r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54140r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54140r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54140r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54140r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54140r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54140r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54140r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54140r=mysqlcfg
Bug #54140 [Opn]: array_merge() break keys during merge
Edit report at http://bugs.php.net/bug.php?id=54140edit=1
ID: 54140
User updated by:forjest at gmail dot com
Reported by:forjest at gmail dot com
Summary:array_merge() break keys during merge
Status: Open
Type: Bug
Package:Arrays related
-Operating System:
+Operating System: *Nix
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
Works as expected on Windows platform.
Previous Comments:
[2011-03-02 18:21:06] forjest at gmail dot com
Description:
array_merge interprets string keys, containing only digits as numeric
keys, if numeric overflow not reached.
String keys should works as strings regarless of their contents.
Test script:
---
var_dump(array_merge(array('t777'= array(I'm a string;
var_dump(array_merge(array(42424242= array(I'm a string of
digits;
var_dump(array_merge(array(7=
array(I'm string of digits too;
var_dump(is_string(42424242));
var_dump(is_string(42424242));
var_dump(is_string(7));
Expected result:
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[42424242]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
Actual result:
--
array(1) {
[t777]=
array(1) {
[0]=
string(12) I'm a string
}
}
array(1) {
[0]=
array(1) {
[0]=
string(22) I'm a string of digits
}
}
array(1) {
[7]=
array(1) {
[0]=
string(24) I'm string of digits too
}
}
bool(true)
bool(false)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54140edit=1
Bug #54128 [Com]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Comment by: carsten_sttgt at gmx dot de
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
PHP Version:5.3.5
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
thus stat should normally work in this folder for own files.
Ups, must correct me. stat (crt) is really not working, even traverse
folder/execute file is allowed.
But I must agree with vavra. Checking the existence of a file is
normally done with (f)open or access. Someone should report this to the
libzip team.
Previous Comments:
[2011-03-02 16:56:15] paj...@php.net
@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated?
Thanks.
The stat problem here is totally unrelated to realpath_r. There is a
reason why
we do it (see my other comment) and I already said that I have to see
what else
we can do to work around this problem without adding more platform
specific
changes in this implementation.
[2011-03-02 15:53:37] carsten_sttgt at gmx dot de
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
[2011-03-02 11:08:58] paj...@php.net
What I mean by alternative solutions. Just not sure now if it is worth
it. Also
sharing one temp for all vhost is not a wised idea :)
[2011-03-02 11:01:39] vavra at 602 dot cz
The right permission for temp folder are default right permission for
Windows Server systems. Microsoft probably has a security reason for not
allowing IUSR_ user for listing a temp dir.
Yes I can fix it by changing permissions or not using Windows Temp dir.
I do not fordid you not testing file existence. I offer not do it by
stat function ;-)
[2011-03-02 10:50:22] paj...@php.net
The bug is a side effect of the permission issue. But we have (I repeat:
we have)
to do the existence check for the reason I explained earlier.
I will see what can be done to still make it works but you better have
to fix your
perms instead.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=54128
--
Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Updated by: paj...@php.net
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
PHP Version:5.3.5
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
No, stat exists for that.
Previous Comments:
[2011-03-02 19:31:39] carsten_sttgt at gmx dot de
thus stat should normally work in this folder for own files.
Ups, must correct me. stat (crt) is really not working, even traverse
folder/execute file is allowed.
But I must agree with vavra. Checking the existence of a file is
normally done with (f)open or access. Someone should report this to the
libzip team.
[2011-03-02 16:56:15] paj...@php.net
@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated?
Thanks.
The stat problem here is totally unrelated to realpath_r. There is a
reason why
we do it (see my other comment) and I already said that I have to see
what else
we can do to work around this problem without adding more platform
specific
changes in this implementation.
[2011-03-02 15:53:37] carsten_sttgt at gmx dot de
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
[2011-03-02 11:08:58] paj...@php.net
What I mean by alternative solutions. Just not sure now if it is worth
it. Also
sharing one temp for all vhost is not a wised idea :)
[2011-03-02 11:01:39] vavra at 602 dot cz
The right permission for temp folder are default right permission for
Windows Server systems. Microsoft probably has a security reason for not
allowing IUSR_ user for listing a temp dir.
Yes I can fix it by changing permissions or not using Windows Temp dir.
I do not fordid you not testing file existence. I offer not do it by
stat function ;-)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=54128
--
Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Bug #54110 [Asn]: tsrm_realpath_r and junction point with denied read access
Edit report at http://bugs.php.net/bug.php?id=54110edit=1
ID: 54110
User updated by:carsten_sttgt at gmx dot de
Reported by:carsten_sttgt at gmx dot de
Summary:tsrm_realpath_r and junction point with denied read
access
Status: Assigned
Type: Bug
Package:Filesystem function related
Operating System: Windows
PHP Version:Irrelevant
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
OK and sorry. So let me add this to this topic...
Assuming a default Windows/IIS installation:
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(realpath($filedata['uri']));
| ?
The result:
| boolean false
But it's a little bit different to the problem above. fopen() etc. is
working. Only realpath() fails. And the patch above doesn't fix this
issue.
Previous Comments:
[2011-02-28 17:38:52] paj...@php.net
The main problem we have is about the incldue/require _once function,
permissions issues (no meta read if no permission (as in no read)),
etc.
I'm working on droping almost all useless path resolution for (f)open
and
related functions. They should do nothing but create the file or the
file
handle, instead of checking each part of the request path.
But that's a very (very) sensible part of php and I'm reluctant to make
changes
too quickly in this area for an edge case. At least not without clear
test
cases.
We have a bunch of tests covering this code but it takes some time to
run them,
fix, re test, etc. So don't hold your breath, it won't happen before
5.3.6 is
released :)
Thanks for your feedback!
[2011-02-28 17:32:31] carsten_sttgt at gmx dot de
I'm also not sure that what you proposed does not break more
that what it solves. I will double check that later in March.
That's ok. BTW, this will also fix Bug #50659 (but read below). In the
meantime: Maybe you want add FILE_SHARE_READ as 3rd Parameters for
CreateFile (to prevent a race condition).
It does not only do that and it is used for more than that.
Oh, look like complicated code for doing some task without description
what the function is doing ;-)
Well, it's resolving a relative path to an absolute one, testing if the
target
exists. And it's resolving symlinks along the path. What else?
(really a pity that GetFinalPathNameByHandle only exists as of Vista.)
Especially the last (and because it's called in most functions, although
the functions can use relative paths directly.) raises some problems. I
guess that's for this openbasedir check?
Well, according to #50659 I have a real live issue for a similar reason
(and why I'm using ASP for one project and not PHP):
Given a WEBSERVER which is using a share Files on FILESERVER
(//FILESERVER/Files).
Files is the directory D:\Files. Some Videos are located at
E:\Videos and there is a junction from D:\Files\Videos to
E:\Videos.
Ok, now on WEBSERVER I'm using PHP to access
//FILESERVER/Files/Videos/. What is PHP doing?
It's resolving the last junction to E:\Videos and thus it's searching
rhis directory on WEBSERVER. Still curious this doesn't happen with
every function:
passtru('//FILESERVER/Files/Videos/foo.mpg'); is working.
$f=fopen('//FILESERVER/Files/Videos/foo.mpg', 'rb'); fpassthru($f);
not.
Well, I guess resolving symlinks should only be done on local drives (or
let CreateFile in fopen doing this job itself).
[2011-02-27 19:51:42] paj...@php.net
Maybe we should think about what this function tsrm_realpath_r is
doing. It's
just resolving a relative path to an absolute one. And it's testing if
the target
exists. Nothing else
It does not only do that and it is used for more than that.
[2011-02-27 19:50:29] paj...@php.net
It is not only about windows (sometimes very confusing) ways to
configure ACL but portability in the way permissions or what we allow or
not work.
I'm also not sure that what you proposed does not break more that what
it solves.
I will double check that later in March.
[2011-02-27 16:58:33] carsten_sttgt at gmx dot de
Junction does work very well.
You have tested this?
| mklink test1 nonexistent
| mklink /j test2 nonexistent
| php -r var_dump(realpath('test1'));
| php -r var_dump(realpath('test2'));
What did you expect? (You can also test it with the sample exe below)
We had similar cases where someone wanted to access stat
info from an unreadable file.
It's a difference, if generic read access is denied, or data read
access. This still allows me
Bug #54128 [Com]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Comment by: carsten_sttgt at gmx dot de
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
PHP Version:5.3.5
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
hmmm,
We also have to test if the file exists,
man 2 access
access, eaccess, faccessat -- check accessibility of a file
man 2 stat
stat, lstat, fstat, fstatat -- get file status
I think access is the winner (especially if there is a known problem
with stat)
Previous Comments:
[2011-03-02 19:37:52] paj...@php.net
No, stat exists for that.
[2011-03-02 19:31:39] carsten_sttgt at gmx dot de
thus stat should normally work in this folder for own files.
Ups, must correct me. stat (crt) is really not working, even traverse
folder/execute file is allowed.
But I must agree with vavra. Checking the existence of a file is
normally done with (f)open or access. Someone should report this to the
libzip team.
[2011-03-02 16:56:15] paj...@php.net
@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated?
Thanks.
The stat problem here is totally unrelated to realpath_r. There is a
reason why
we do it (see my other comment) and I already said that I have to see
what else
we can do to work around this problem without adding more platform
specific
changes in this implementation.
[2011-03-02 15:53:37] carsten_sttgt at gmx dot de
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
[2011-03-02 11:08:58] paj...@php.net
What I mean by alternative solutions. Just not sure now if it is worth
it. Also
sharing one temp for all vhost is not a wised idea :)
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=54128
--
Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Bug #54104 [Com]: ldap_sasl_bind fails but not the first time
Edit report at http://bugs.php.net/bug.php?id=54104edit=1 ID: 54104 Comment by: thihfernandes at gmail dot com Reported by:mmx at riz dot pl Summary:ldap_sasl_bind fails but not the first time Status: Open Type: Bug Package:LDAP related Operating System: linux PHP Version:5.2.17 Block user comment: N Private report: N New Comment: With me it's happening the same thing! My PHP version is 5.3.3-7. Previous Comments: [2011-02-26 13:20:05] mmx at riz dot pl Description: When using ldap_sasl_bind to bind to active directory the connection is successful only the first time. When executing the script a second time shortly after the first execution the bind fails. After around 2 minutes the bind is again possible. I suspect that it ma be related to digest md5 fast reauth. The sample code when executed via web server http://my_apache_server/ldap.php it binds succesfully the first time. hitting F5 in the browser: Warning: ldap_sasl_bind() [function.ldap-sasl-bind]: Unable to bind to server: Invalid credentials After 2 minutes it works again for the first time. This problem never happens when I execude the script via command line: php -q ./ldap.php any number of times in a row. on tcpdump I see that the nonce-count is inceasing. the first failure has nc=0002. after waiting 2 minutes I see that nc starts back from 1. when starting php -q ./ldap.php the nc has always the nc=0001. My conclusion is that there is some kind of cache/fast reauth/session when php generates the error when working as a part of httpd. After ivestigating netstat I noticed that the second bind fails until I see on netstat the connection in the TIME_WAIR state: netstat -anpe|grep 389 tcp0 0 client:42457ad_server:389 TIME_WAIT 0 0 - when the connection finally dissapears the first sasl bind is successful. Of course when I hit F5 many time I have many connections with TIME_WAIT state. After all of them dissapear the bind is successfull only for the first time. Test script: --- $conn = @ldap_connect( ad_server )); ldap_set_option ( $conn, LDAP_OPT_PROTOCOL_VERSION, 3)); ldap_sasl_bind ( $conn, NULL, password,'DIGEST-MD5','my_realm','ldap_username',NULL); Expected result: successful sasl bind without the need to wait 2 minutes. Actual result: -- when the code is executed the second time Warning: ldap_sasl_bind() [function.ldap-sasl-bind]: Unable to bind to server: Invalid credentials -- Edit this bug report at http://bugs.php.net/bug.php?id=54104edit=1
[PHP-BUG] Bug #54141 [NEW]: Function symlink not working under windows server 2008
From: Operating system: Windows server 2008 PHP version: 5.3.5 Package: IIS related Bug Type: Bug Bug description:Function symlink not working under windows server 2008 Description: --- From manual page: http://www.php.net/function.symlink --- I am under Windows server 2008 PHP 3.5.3 installed with FastCGI I get this error when I can the function symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 Test script: --- symlink(C:\Temp\php.log,C:\Temp\symlink.log); Expected result: The symlink Actual result: -- No symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 -- Edit bug report at http://bugs.php.net/bug.php?id=54141edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54141r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54141r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54141r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54141r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54141r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54141r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54141r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54141r=needscript Try newer version: http://bugs.php.net/fix.php?id=54141r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54141r=support Expected behavior: http://bugs.php.net/fix.php?id=54141r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54141r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54141r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54141r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54141r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54141r=dst IIS Stability: http://bugs.php.net/fix.php?id=54141r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54141r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54141r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54141r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54141r=mysqlcfg
Bug #54141 [Opn]: Function symlink not working under windows server 2008
Edit report at http://bugs.php.net/bug.php?id=54141edit=1 ID: 54141 User updated by:shibby_crinquer at hotmail dot com Reported by:shibby_crinquer at hotmail dot com Summary:Function symlink not working under windows server 2008 Status: Open Type: Bug Package:IIS related Operating System: Windows server 2008 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: When I go in the command prompt and enter C:\php\ php index.php that contain the symlink command, it work. But outside the command prompt (in a web page) it don't work. I've looked about changing the local policies for the Create symbolic links I've changed Administrators for everyone and this is not working. Previous Comments: [2011-03-02 21:46:57] shibby_crinquer at hotmail dot com Description: --- From manual page: http://www.php.net/function.symlink --- I am under Windows server 2008 PHP 3.5.3 installed with FastCGI I get this error when I can the function symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 Test script: --- symlink(C:\Temp\php.log,C:\Temp\symlink.log); Expected result: The symlink Actual result: -- No symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 -- Edit this bug report at http://bugs.php.net/bug.php?id=54141edit=1
[PHP-BUG] Bug #54142 [NEW]: the function mysqli_insert_id doesn't return the last id
From:
Operating system: windows
PHP version: 5.2.17
Package: PHP options/info functions
Bug Type: Bug
Bug description:the function mysqli_insert_id doesn't return the last id
Description:
---
From manual page: http://www.php.net/mysqli.insert-id#Descripción
---
The function mysqli_insert_id does not return the if of the last insert.
The
query was executed without problem but I can get the id of this insert. I
want to
konw if exist other function other possiblity, maybe I need to reconfigure
some
value in the php ini, but I need a solution and this solution must be in
the
documents of this funcionality.
I'm adding the function that I have for insert a row.
Test script:
---
function insert($ins)
{
$result = @mysqli_query($this-conn,$ins);
if (!$result)
{
$this-writeTemplate(DB_TITULO_ERROR,mysqli_error());
}
return @mysqli_insert_id($this-conn);
}
Expected result:
- A solution to use correctly this function
- Id does not exist a solution with this function, another solution with
other
functions of mysql
Actual result:
--
the function returns a empty object.
--
Edit bug report at http://bugs.php.net/bug.php?id=54142edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54142r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54142r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54142r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54142r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54142r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54142r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54142r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54142r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54142r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54142r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54142r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54142r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54142r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54142r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54142r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54142r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54142r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54142r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54142r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54142r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54142r=mysqlcfg
[PHP-BUG] Bug #54143 [NEW]: array_merge returns NULL if a parameter is NULL
From: Operating system: Ubuntu 9.3 PHP version: 5.3SVN-2011-03-02 (SVN) Package: Arrays related Bug Type: Bug Bug description:array_merge returns NULL if a parameter is NULL Description: $userdata = array_merge($user, $userdata); If $user is NULL the result is NULL instead of $userdata. Test script: --- $userdata = array(Hi, Jim); $userdata = array_merge(NULL, $userdata); Expected result: Get back $userdata = array(Hi, Jim) Actual result: -- NULL -- Edit bug report at http://bugs.php.net/bug.php?id=54143edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54143r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54143r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54143r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54143r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54143r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54143r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54143r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54143r=needscript Try newer version: http://bugs.php.net/fix.php?id=54143r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54143r=support Expected behavior: http://bugs.php.net/fix.php?id=54143r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54143r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54143r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54143r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54143r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54143r=dst IIS Stability: http://bugs.php.net/fix.php?id=54143r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54143r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54143r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54143r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54143r=mysqlcfg
Bug #54128 [Asn]: ZIP_ER_OPEN when ZipArchive::open() on temp file
Edit report at http://bugs.php.net/bug.php?id=54128edit=1
ID: 54128
Updated by: paj...@php.net
Reported by:vavra at 602 dot cz
Summary:ZIP_ER_OPEN when ZipArchive::open() on temp file
Status: Assigned
Type: Bug
Package:Zip Related
Operating System: Windows 2003
PHP Version:5.3.5
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
This problem is new to me and again, there are reasons why we use it.
In any case, thanks for the feedback, the problem is identified and has
sufficient
info. I will try to figure a portable way to make this special case
working.
Previous Comments:
[2011-03-02 19:53:19] carsten_sttgt at gmx dot de
hmmm,
We also have to test if the file exists,
man 2 access
access, eaccess, faccessat -- check accessibility of a file
man 2 stat
stat, lstat, fstat, fstatat -- get file status
I think access is the winner (especially if there is a known problem
with stat)
[2011-03-02 19:37:52] paj...@php.net
No, stat exists for that.
[2011-03-02 19:31:39] carsten_sttgt at gmx dot de
thus stat should normally work in this folder for own files.
Ups, must correct me. stat (crt) is really not working, even traverse
folder/execute file is allowed.
But I must agree with vavra. Checking the existence of a file is
normally done with (f)open or access. Someone should report this to the
libzip team.
[2011-03-02 16:56:15] paj...@php.net
@carsten_sttgt at gmx dot de
Can you please for my own sanity keep separate issues separated?
Thanks.
The stat problem here is totally unrelated to realpath_r. There is a
reason why
we do it (see my other comment) and I already said that I have to see
what else
we can do to work around this problem without adding more platform
specific
changes in this implementation.
[2011-03-02 15:53:37] carsten_sttgt at gmx dot de
I assume it is similar on Windows.
Yes. In this case the needed X-Bit (X = directory traversal) is still
set. Thus you can cd to this directory. But on Windows we have an
additional right RD (list directory). This one is not allowed, and so
you can't do a dir in this directory.
- thus stat should normally work in this folder for own files.
Also sharing one temp for all vhost is not a wised idea :)
If all vhosts have a (scripts are executed with a) different SID, that's
not a problem. Only the creator SID (and admin/system) have full access
to it own files in this folder, but no rights to files created from
other SID's. (a little bit like 1777 on *nix. But an *nix you can still
list other files. On Win not.)
But back to the topic and let me extend the testscript:
| ?php
| $zipfile = tempnam(sys_get_temp_dir(), 'zip');
| $zip = new ZipArchive();
|
| $res = $zip-open($zipfile, ZIPARCHIVE::CREATE);
| if ($res !== true) {
| printf(Can't create file (%d), $res);
| }
| var_dump($res);
| $zip-close();
|
| $res = $zip-open($zipfile);
| if ($res !== true) {
| printf(Can't open file (%d), $res);
| }
|
|
| unlink($zipfile);
| ?
The result:
| boolean true
| Can't open file (11)
I can create a new Zip-File in this folder, but can't open an existing
one.
BTW stat(). Here's an example with PHP stat() (and my favorite
realpath):
| ?php
| $temp = tmpfile();
| $filedata = stream_get_meta_data($temp);
| var_dump(stat($filedata['uri']));
| var_dump(realpath($filedata['uri']));
| ?
The result:
| array (size=26)
| 0 = int 2
| ...
| boolean false
tmpfile, fopen, stat, whatever is working in this dir. But realpath
fails...
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=54128
--
Edit this bug report at http://bugs.php.net/bug.php?id=54128edit=1
Bug #54141 [Opn-Bgs]: Function symlink not working under windows server 2008
Edit report at http://bugs.php.net/bug.php?id=54141edit=1 ID: 54141 Updated by: paj...@php.net Reported by:shibby_crinquer at hotmail dot com Summary:Function symlink not working under windows server 2008 -Status: Open +Status: Bogus Type: Bug Package:IIS related Operating System: Windows server 2008 PHP Version:5.3.5 Block user comment: N Private report: N New Comment: Permissions issue, fix them and you will be able to create symbolic links. Previous Comments: [2011-03-02 22:05:53] shibby_crinquer at hotmail dot com When I go in the command prompt and enter C:\php\ php index.php that contain the symlink command, it work. But outside the command prompt (in a web page) it don't work. I've looked about changing the local policies for the Create symbolic links I've changed Administrators for everyone and this is not working. [2011-03-02 21:46:57] shibby_crinquer at hotmail dot com Description: --- From manual page: http://www.php.net/function.symlink --- I am under Windows server 2008 PHP 3.5.3 installed with FastCGI I get this error when I can the function symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 Test script: --- symlink(C:\Temp\php.log,C:\Temp\symlink.log); Expected result: The symlink Actual result: -- No symlink. Warning: symlink(): Cannot create symlink, error code(1314) in C:\inetpub\wwwroot\index.php on line 42 -- Edit this bug report at http://bugs.php.net/bug.php?id=54141edit=1
Req #40510 [Asn]: Add multicast support in sockets.c
Edit report at http://bugs.php.net/bug.php?id=40510edit=1 ID: 40510 Updated by: cataphr...@php.net Reported by:lew dot payne at gmail dot com Summary:Add multicast support in sockets.c Status: Assigned Type: Feature/Change Request Package:*General Issues Operating System: FreeBSD 6.2-REL PHP Version:5.2.1 Assigned To:cataphract Block user comment: N Private report: N New Comment: Chris, PHP 5.2 is dead, adding this feature to it is out of question. Adding it to PHP 5.3 depends on the release master, but probably won't be possible due to the need to keep binary compatibility. Previous Comments: [2011-03-02 11:08:52] chrisw at networkm dot co dot uk Judging by the amount of Google space taken up by people trying to do this (including myself) I am very much in favour of moving this issue forward ASAP. I also agree with the IPv6 support (to a point), but if this is to be added to PHP 5.2.x I would suggest it may not be necessary to implement at this stage. Moving forward, shouldn't we be encouraging the use of 5.3.x for new/upgrading users? In which case, I would suggest that adding full IPv6 support against 5.2 might be a waste of time - I would imagine there would be a lot of work involved in adding full IPv6 multicast/anycast support, whereas the existing supplied patch would presumably only require minor modifications to bring it into line with the current 5.2 releases. I am all in favour of fully supporting IPv6 in 5.3, but I also believe that in the interests of speed it would be useful to have this, simpler, IPv4 multicast support in 5.2. Maybe this would be considered an un-productive approach, but it's just a thought... [2011-03-02 10:43:32] cataphr...@php.net I understand you're frustrated with the lack of progress in this issue, but I assigned this to myself because I intend to implement this feature soon (read: in a matter of weeks, not years). [2011-03-02 05:01:20] lew dot payne at gmail dot com This ticket was opened four years ago, at which time I supplied source code that I had modified to work on FreeBSD (the original only worked on Linux). If you want to seriously consider IPV6 support, please seriously consider finally integrating this patch, and then waiting another four years before considering IPV6. Yes, I'm being sarcastic... but with good reason. I was basically given the runaround, via email with whomever looks at these bug reports, to the point where I simply decided it's easier to *not* contribute anything. I find it both irritating and ironic that, four years later, there is yet another suggestion on delaying the commitment of this patch (e.g., IPV6). And you think government is discouraging and bureaucratic? [2011-02-27 17:15:53] cataphr...@php.net I think IPv6 support should be seriously considered before committing a multicast patch. [2011-02-27 09:48:11] paj...@php.net Please provide an updated patch and phpt against trunk The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=40510 -- Edit this bug report at http://bugs.php.net/bug.php?id=40510edit=1
[PHP-BUG] Req #54144 [NEW]: add php.ini option for syslog program name
From: Operating system: all unix-likes PHP version: Irrelevant Package: PHP options/info functions Bug Type: Feature/Change Request Bug description:add php.ini option for syslog program name Description: It would be useful to configure the syslog program name in php.ini (or httpd.conf for mod_php). The appended patch adds two config variables 'syslog.program' and 'syslog.pid'. I am using it for one year now on a shared webserver; it enables me to use syslog for central log collection, associate logged errors with users, and give all users access to their own log data. -- Edit bug report at http://bugs.php.net/bug.php?id=54144edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54144r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54144r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54144r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54144r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54144r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54144r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54144r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54144r=needscript Try newer version: http://bugs.php.net/fix.php?id=54144r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54144r=support Expected behavior: http://bugs.php.net/fix.php?id=54144r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54144r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54144r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54144r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54144r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54144r=dst IIS Stability: http://bugs.php.net/fix.php?id=54144r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54144r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54144r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54144r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54144r=mysqlcfg
[PHP-BUG] Bug #54145 [NEW]: DateTime-add is not affected by DST changes
From: Operating system: all? PHP version: 5.3.5 Package: Date/time related Bug Type: Bug Bug description:DateTime-add is not affected by DST changes Description: hi when dateinterval walks across a dst change $a = DateTime::createFromFormat ( d/m/Y H:i:s e, 03/03/2011 01:38:25 europe/rome ); $a = $a-add(new DateInterval(P1M)); // now we have DST in italy should add +1 hour too, I think, but it doesn't thank you -- Edit bug report at http://bugs.php.net/bug.php?id=54145edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54145r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54145r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54145r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54145r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54145r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54145r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54145r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54145r=needscript Try newer version: http://bugs.php.net/fix.php?id=54145r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54145r=support Expected behavior: http://bugs.php.net/fix.php?id=54145r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54145r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54145r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54145r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54145r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54145r=dst IIS Stability: http://bugs.php.net/fix.php?id=54145r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54145r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54145r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54145r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54145r=mysqlcfg
Bug #54145 [Com]: DateTime-add is not affected by DST changes
Edit report at http://bugs.php.net/bug.php?id=54145edit=1 ID: 54145 Comment by: giorgio dot liscio at email dot it Reported by:giorgio dot liscio at email dot it Summary:DateTime-add is not affected by DST changes Status: Open Type: Bug Package:Date/time related Operating System: all? PHP Version:5.3.5 Block user comment: N Private report: N New Comment: proposed solution: -add and -sub methods should internally convert to UTC before add or sub the interval, then should re-set the original timezone Previous Comments: [2011-03-03 01:51:35] giorgio dot liscio at email dot it Description: hi when dateinterval walks across a dst change $a = DateTime::createFromFormat ( d/m/Y H:i:s e, 03/03/2011 01:38:25 europe/rome ); $a = $a-add(new DateInterval(P1M)); // now we have DST in italy should add +1 hour too, I think, but it doesn't thank you -- Edit this bug report at http://bugs.php.net/bug.php?id=54145edit=1
[PHP-BUG] Bug #54146 [NEW]: 0 not valid float
From:
Operating system: OSX and Linux
PHP version: 5.3SVN-2011-03-03 (SVN)
Package: Filter related
Bug Type: Bug
Bug description:0 not valid float
Description:
---
From manual page: http://www.php.net/filter.filters.validate
---
As I understand the documentation, 0 (zero) should be a valid float, but it
fails
while testing.
Test script:
---
?php
$var=0;
if (!filter_var($var, FILTER_VALIDATE_FLOAT))
{
echo Not valid;
}
else
{
echo Valid;
}
?
--
Edit bug report at http://bugs.php.net/bug.php?id=54146edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54146r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54146r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54146r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54146r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54146r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54146r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54146r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54146r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54146r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54146r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54146r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54146r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54146r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54146r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54146r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54146r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54146r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54146r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54146r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54146r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54146r=mysqlcfg
[PHP-BUG] Bug #54147 [NEW]: debug_backtrace increases memory usage
From:
Operating system: Red Hat Linux
PHP version: 5.2.17
Package: Unknown/Other Function
Bug Type: Bug
Bug description:debug_backtrace increases memory usage
Description:
Calling debug_backtrace(false) can lead to a huge increase in memory usage,
if
it's called from within a function that was passed a huge string as an
argument.
This is because the string will be duplicated in the args field of the
result.
It would be nice to have another boolean argument to debug_backtrace, that
would
tell it to skip the args field. This would be similar to the one that
skips the
object field.
Or could the arguments be returned as references, so they don't increase
memory
usage?
Test script:
---
function test($str) {
echo before: .round(memory_get_usage()/1024/1024, 2). MB\n;
debug_backtrace(false);
echo after: .round(memory_get_usage()/1024/1024, 2). MB\n;
}
test(str_repeat('a', 1000));
Expected result:
before: 9.59 MB
after: 9.59 MB
(This is what I get if I remove the debug_backtrace() call.)
Actual result:
--
before: 9.59 MB
after: 19.12 MB
--
Edit bug report at http://bugs.php.net/bug.php?id=54147edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54147r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54147r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54147r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54147r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54147r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54147r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54147r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54147r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54147r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54147r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54147r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54147r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54147r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54147r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54147r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54147r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54147r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54147r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54147r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54147r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54147r=mysqlcfg
Bug #54145 [Opn-Bgs]: DateTime-add is not affected by DST changes
Edit report at http://bugs.php.net/bug.php?id=54145edit=1
ID: 54145
Updated by: dtajchre...@php.net
Reported by:giorgio dot liscio at email dot it
Summary:DateTime-add is not affected by DST changes
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: all?
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
david@copenhagen:~/test$ php -v
PHP 5.3.6-dev (cli) (built: Feb 26 2011 23:29:38) (DEBUG)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
david@copenhagen:~/test$ cat t.php
?php
date_default_timezone_set('America/Chicago');
$d = new DateTime('03-march-2011');
var_dump($d-format('c'));
$d-add(new DateInterval('P1M'));
var_dump($d-format('c'));
date_default_timezone_set('Europe/Rome');
$d = new DateTime('03-march-2011');
var_dump($d-format('c'));
$d-add(new DateInterval('P1M'));
var_dump($d-format('c'));
david@copenhagen:~/test$ php t.php
string(25) 2011-03-03T00:00:00-06:00
string(25) 2011-04-03T00:00:00-05:00
string(25) 2011-03-03T00:00:00+01:00
string(25) 2011-04-03T00:00:00+02:00
david@copenhagen:~/test$
Previous Comments:
[2011-03-03 02:03:27] giorgio dot liscio at email dot it
proposed solution:
-add and -sub methods should internally convert to UTC before add or
sub the interval, then should re-set the original timezone
[2011-03-03 01:51:35] giorgio dot liscio at email dot it
Description:
hi
when dateinterval walks across a dst change
$a = DateTime::createFromFormat
(
d/m/Y H:i:s e,
03/03/2011 01:38:25 europe/rome
);
$a = $a-add(new DateInterval(P1M)); // now we have DST in italy
should add +1 hour too, I think, but it doesn't
thank you
--
Edit this bug report at http://bugs.php.net/bug.php?id=54145edit=1
Bug #54142 [Opn-Bgs]: the function mysqli_insert_id doesn't return the last id
Edit report at http://bugs.php.net/bug.php?id=54142edit=1
ID: 54142
Updated by: dtajchre...@php.net
Reported by:lissetteganoza at gmail dot com
Summary:the function mysqli_insert_id doesn't return the
last id
-Status: Open
+Status: Bogus
Type: Bug
Package:PHP options/info functions
Operating System: windows
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
david@copenhagen:~/test$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 64
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql describe test;
+---+--+--+-+-++
| Field | Type | Null | Key | Default | Extra |
+---+--+--+-+-++
| pid | int(10) unsigned | NO | PRI | NULL| auto_increment |
| n_pid | date | NO | | NULL||
+---+--+--+-+-++
2 rows in set (0.00 sec)
mysql select * from test;
+-++
| pid | n_pid |
+-++
| 1 | 2011-03-02 |
+-++
1 row in set (0.00 sec)
mysql exit
Bye
david@copenhagen:~/test$ cat t.php
?php
$l = mysqli_connect('127.0.0.1', 'root', 'root');
var_dump(mysqli_select_db($l, 'test'));
var_dump(mysqli_query($l, 'insert into test (n_pid)
values(curdate())'));
var_dump(mysqli_insert_id($l));
david@copenhagen:~/test$ /home/david/dev/php/php53/sapi/cli/php -v
PHP 5.3.6-dev (cli) (built: Feb 26 2011 23:29:38) (DEBUG)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
david@copenhagen:~/test$ /home/david/dev/php/php53/sapi/cli/php t.php
bool(true)
bool(true)
int(9)
david@copenhagen:~/test$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 66
Server version: 5.1.41-3ubuntu12.10 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input
statement.
mysql use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql select * from test;
+-++
| pid | n_pid |
+-++
| 1 | 2011-03-02 |
| 9 | 2011-03-02 |
+-++
2 rows in set (0.00 sec)
mysql exit
Bye
david@copenhagen:~/test$
Previous Comments:
[2011-03-02 22:42:17] lissetteganoza at gmail dot com
Description:
---
From manual page: http://www.php.net/mysqli.insert-id#Descripción
---
The function mysqli_insert_id does not return the if of the last
insert. The
query was executed without problem but I can get the id of this insert.
I want to
konw if exist other function other possiblity, maybe I need to
reconfigure some
value in the php ini, but I need a solution and this solution must be in
the
documents of this funcionality.
I'm adding the function that I have for insert a row.
Test script:
---
function insert($ins)
{
$result = @mysqli_query($this-conn,$ins);
if (!$result)
{
$this-writeTemplate(DB_TITULO_ERROR,mysqli_error());
}
return @mysqli_insert_id($this-conn);
}
Expected result:
- A solution to use correctly this function
- Id does not exist a solution with this function, another solution with
other
functions of mysql
Actual result:
--
the function returns a empty object.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54142edit=1
Req #54037 [Opn]: [PATCH] Adds the ability to pass options to loadHTML
Edit report at http://bugs.php.net/bug.php?id=54037edit=1 ID: 54037 Updated by: chr...@php.net Reported by:fxmulder at gmail dot com Summary:[PATCH] Adds the ability to pass options to loadHTML Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:trunk-SVN-2011-02-17 (SVN) Block user comment: N Private report: N New Comment: After talking with Rob, we removed LIBXML_RECOVER again. People don't like seeing that wildly used, there were and are always a lot of discussions, if that's a good thing at all. So we just remove the constant again for now. I'll attach the new patch. If noone complains, I will commit it soon Previous Comments: [2011-02-22 17:11:08] chr...@php.net Looks fine to me, Will commit soon to trunk [2011-02-18 00:21:20] fxmulder at gmail dot com I've also included a patch to create new constants for use as options [2011-02-17 18:57:57] fxmulder at gmail dot com Description: This patch allows passing options directly to libxml for the loadHTML and loadHTMLFile DOMDocument functions -- Edit this bug report at http://bugs.php.net/bug.php?id=54037edit=1
Req #54037 [PATCH]: [PATCH] Adds the ability to pass options to loadHTML
Edit report at http://bugs.php.net/bug.php?id=54037edit=1 ID: 54037 Patch added by: chr...@php.net Reported by:fxmulder at gmail dot com Summary:[PATCH] Adds the ability to pass options to loadHTML Status: Open Type: Feature/Change Request Package:DOM XML related PHP Version:trunk-SVN-2011-02-17 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: patch-for-adding-loadhtml-options.patch Revision: 1299136320 URL: http://bugs.php.net/patch-display.php?bug=54037patch=patch-for-adding-loadhtml-options.patchrevision=1299136320 Previous Comments: [2011-03-03 08:11:04] chr...@php.net After talking with Rob, we removed LIBXML_RECOVER again. People don't like seeing that wildly used, there were and are always a lot of discussions, if that's a good thing at all. So we just remove the constant again for now. I'll attach the new patch. If noone complains, I will commit it soon [2011-02-22 17:11:08] chr...@php.net Looks fine to me, Will commit soon to trunk [2011-02-18 00:21:20] fxmulder at gmail dot com I've also included a patch to create new constants for use as options [2011-02-17 18:57:57] fxmulder at gmail dot com Description: This patch allows passing options directly to libxml for the loadHTML and loadHTMLFile DOMDocument functions -- Edit this bug report at http://bugs.php.net/bug.php?id=54037edit=1
