#43182 [NEW]: file_put_contents' LOCK_EX flag is useless with advisory locking
From: chris_se at gmx dot net
Operating system: Any POSIX-compatible OS
PHP version: 5.2.4
PHP Bug Type: Streams related
Bug description: file_put_contents' LOCK_EX flag is useless with advisory
locking
Description:
The LOCK_EX flag of file_put_contents suggests that the function will use
an advisory lock to ensure transaction safety. This is NOT the case (except
when combined with FILE_APPEND). It actually DOES request an exclusive lock
on the file but only does so AFTER opening it in the 'wb' mode which will
truncate the file on opening BEFORE the actual lock can be acquired.
The correct behaviour would be to open the file for writing without
truncating it, in C for example using
int fileno = open (file, O_WRONLY | O_CREAT, 0666);
(WITHOUT adding O_TRUNC!), THEN acquiring the lock using flock() and THEN
truncating the file to 0 bytes length.
I don't know if there's a simple possibility to integrate it with the
current streams API (since there's no fopen mode that will map to either
O_WRONLY | O_CREAT or O_RWDR | O_CREAT) but if it's not possible to fix it,
you should at least remove the option, since it suggests something it can't
provide with advisory locking.
This is not a problem on Windows since Windows locks are always mandatory.
Reproduce code:
---
First script (start in in a first window using any P):
?php
file_put_contents ('file.txt', 'Hello World!');
$f = fopen ('file.txt', 'r') or die (Could not open file!\n);
flock ($f, LOCK_SH) or die (Could not acaquire lock!\n);
echo Sleeping for 20 seconds (please use file_put_contents script in the
mean time!)\n;
sleep (20);
$x .= fread ($f, 1024);
fclose ($f);
echo Contents was: ' . $x . '\n;
?
Second script (start it in a second window in the same directory while the
first one is sleeping):
?php
file_put_contents ('file.txt', 'ByeBye Joe!', LOCK_EX);
?
Expected result:
The first script should output:
Sleeping for 20 seconds (please use file_put_contents script in the mean
time!)
Contents was: 'Hello World!'
Actual result:
--
The first script outputs:
Sleeping for 20 seconds (please use file_put_contents script in the mean
time!)
Contents was: ''
--
Edit bug report at http://bugs.php.net/?id=43182edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43182r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43182r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43182r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43182r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43182r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43182r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43182r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43182r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43182r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43182r=support
Expected behavior:http://bugs.php.net/fix.php?id=43182r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43182r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43182r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43182r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43182r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43182r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43182r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43182r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43182r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43182r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43182r=mysqlcfg
#43183 [NEW]: importing the same class in difference scripts results in a fatal error
From: [EMAIL PROTECTED]
Operating system: n/a (linux 2.6, mac os x 10.4)
PHP version: 5.3CVS-2007-11-03 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: importing the same class in difference scripts results in a
fatal error
Description:
As per discussion on the PHP internals list, the proper way to ensure that
when using a short name, the class loaded is always from the current
namespace (even if it needs to be autoloaded and has not yet been loaded)
is to import that class in every file where it is used.
However, doing so in two separate scripts, OR just importing a class that
has already been defined in the namespace, can result in a fatal error
claiming an import clash. Because of the nature of namespaces and this bug
it requires 2 small scripts to reproduce, not one.
Reproduce code:
---
ns_import1.php:
---
?php
namespace Test;
class Helper {}
include dirname(__FILE__) . '/ns_import2.php';
ns_import2.php:
---
?php
namespace Test;
import Test::Helper;
class Other {}
Expected result:
No error, should be no output.
Actual result:
--
$ php ns_import1.php
Fatal error: Import name 'Helper' conflicts with defined class in
/tmp/ns_import2.php on line 5
--
Edit bug report at http://bugs.php.net/?id=43183edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43183r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43183r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43183r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43183r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43183r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43183r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43183r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43183r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43183r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43183r=support
Expected behavior:http://bugs.php.net/fix.php?id=43183r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43183r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43183r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43183r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43183r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43183r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43183r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43183r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43183r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43183r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43183r=mysqlcfg
#22666 [Com]: POST only passing a limited number of form variables
ID: 22666 Comment by: xeenych at gmail dot com Reported By: lbravo at nc dot rr dot com Status: No Feedback Bug Type: *General Issues Operating System: WIndows 2000 PHP Version: 4.3.0 New Comment: I also encountered this bug Os: Windows XP SP2 PHP: 5.2.4-win32 The problem is the following. I create a stream context with some (2) form variables and issue a POST request to a redirecting page on a remote webserver using fopen() or file_get_contents() Using packet sniffer i discovered, that remote webserver responds HTTP 1.1 302 found and sends location = someotherpage.php Then, file_get_contents() follows redirect and sends another POST request for the page someotherpage.php, but this request appears to be trashed with some form variables from the very first request. In best case, when there are 2 or may be 3 form variables, remote server sends error 411 - length required In worst, it sends Bad request. Previous Comments: [2003-03-19 16:49:21] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-03-12 17:09:38] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2003-03-12 15:55:18] lbravo at nc dot rr dot com I encountered a problem when passing about 20+ variables in the context of form variables. The same problem occurs if using arrays in the context of form variables. Only a certain number are passed, generally those that appear first before the submit are passed, the exact number seems to vary some what. I have created simple php scripts and tested with the same results. I am not sure if the actual naming makes a difference or not, the results seem to vary depending on how you try to set up the test. I am very puzzled, with this behavior. -- Edit this bug report at http://bugs.php.net/?id=22666edit=1
#43184 [NEW]: PHP outputs a weird error in the CGI log.
From: trustpunk at gmail dot com Operating system: Windows PHP version: 5.2.5RC2 PHP Bug Type: CGI related Bug description: PHP outputs a weird error in the CGI log. Description: I don't have any errors in my PHP code but I see that in my CGI log, I have this weird error. This shows up with every PHP release I download. Reproduce code: --- Just run a few PHP pages on your server and you will get the nasty error posted below in your CGI log file. Note: This happens every time a new instance of php-cgi.exe is started. !---CGI LOG--- 03/Nov/2007:15:30:45 -0500 SUID: 0 PUID: 0 RUID: 0 URI:Reading 0 bytes failed = The process cannot access the file because it is being used by another process. 03/Nov/2007:15:30:45 -0500 SUID: 0 PUID: 0 RUID: 0 URI:timeout-header2! Expected result: I don't want to see that error in my CGI log file again. What is going on? Actual result: -- !---CGI LOG--- 03/Nov/2007:15:30:45 -0500 SUID: 0 PUID: 0 RUID: 0 URI:Reading 0 bytes failed = The process cannot access the file because it is being used by another process. 03/Nov/2007:15:30:45 -0500 SUID: 0 PUID: 0 RUID: 0 URI:timeout-header2! !---End of CGI LOG--- It never stops! It just keeps logging that garbage every few requests. -- Edit bug report at http://bugs.php.net/?id=43184edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43184r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43184r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43184r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43184r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43184r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43184r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43184r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43184r=needscript Try newer version:http://bugs.php.net/fix.php?id=43184r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43184r=support Expected behavior:http://bugs.php.net/fix.php?id=43184r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43184r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43184r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43184r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43184r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43184r=dst IIS Stability:http://bugs.php.net/fix.php?id=43184r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43184r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43184r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43184r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43184r=mysqlcfg
