#23406 [Asn]: \r\n not functioning the same from 4.3.1 and prior

From: Date: Sun, 18 May 2003 00:22:26 +0000
Subject: #23406 [Asn]: \r\n not functioning the same from 4.3.1 and prior
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-39857@lists.php.net to get a copy of this message
ID: 23406 User updated by: gfraley5 at earthlink dot net Reported By: gfraley5 at earthlink dot net Status: Assigned Bug Type: Filesystem function related Operating System: Win98SE,WinXP,Win2K PHP Version: 4.3.2RC2 Assigned To: wez New Comment: I would disagree. Since it was never manadatory to use the 'wb' then making a change that forces it, needs to be announced, imo. Otherwise, files will be ruined if the circumstances mentioned here are used. Previous Comments: ------------------------------------------------------------------------ [2003-05-15 13:22:52] sniper@php.net For me this looks like bogus. ------------------------------------------------------------------------ [2003-05-01 09:24:06] wez@php.net The reason for the change was primarily to avoid crippling limitations for the number of opened files under Solaris, but has other benefits for the streams API. My opinion of the backwards compatibility issue here is that it should be a non-issue; the fopen() docs have warned about binary mode for a very long time. However, I think we will wait and see if we get any more feedback on this issue before making a firm decision. ------------------------------------------------------------------------ [2003-05-01 09:18:37] gfraley5 at earthlink dot net Thanks! I have submitted this in the past and it was rebuffed and marked as bogus. I don't think it should be marked as bogus because it is a definite backward compatability issue that will render files useless (as it does with hundreds of my users that use legacy 'w' instead of 'wb') if written to without the 'B' attribute. If anything, it could/should be marked as an 'enhancement' or something as you have changed the behavior whether intentionally or not. Was there a specific reason why you wnet to the lower level call open()? If nothing in particular, then maybe you leave 4.3.2 as is and prepare the public and developers for the change in a future release. Just a thought. ------------------------------------------------------------------------ [2003-05-01 09:11:49] wez@php.net The Apache SAPI leaves the _fmode variable as-is, whereas the CLI, CGI and Embed SAPIs all force it to binary mode. What this means is that for the latter three, fopen($file, "r") is forced to fopen($file, "rb") internally by the MS libc. Technically speaking this behaviour is a bit naughty, as it prevents opening files in text-mode when using CLI and CGI, and Embed interferes with the hosting application's binary settings (this is the main reason we don't set it in Apache). I can't find any logical reason for the apparent change in behaviour under Apache, except for the fact that we are now using the lower level file descriptors returned by _open() rather than calling the slightly higher level fopen() to get at the files. Why this makes a difference, I can't tell (it just doesn't make sense). However, all of this aside, the behaviour you are currently experiencing under Apache is the technically correct behaviour that you should expect when opening a file in text mode. The correct fix for your problem is to open the file in binary mode, as is suggested in the PHP manual for the fopen() function, and in numerous places throughout the manual when talking about binary safety. I'm tempted to mark this report as bogus (because it is the expected behaviour), but want to discuss the implications of this with some of the other developers first, because of potential backwards compatibility issues. ------------------------------------------------------------------------ [2003-04-30 13:58:38] gfraley5 at earthlink dot net Apache ------------------------------------------------------------------------ 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/23406 -- Edit this bug report at http://bugs.php.net/?id=23406&edit=1

« previous php.bugs (#39857) next »