php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #28371 Different behaviour of fopen depending on r+,w+,a+
Submitted: 2004-05-12 17:20 UTC Modified: 2005-04-29 16:21 UTC
From: rc at opelgt dot org Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 4.3.4 OS: MacOSX 10.3
Private report: No CVE-ID:
 [2004-05-12 17:20 UTC] rc at opelgt dot org

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-05-12 18:52 UTC] wez@php.net
The output under both linux and OSX is:

Inhalt<BR>
alt: 1234567890<BR>
neu: 13579

Your bug report doesn't sound so much like a bug report, but a support request; this isn't a support forum, so if you don't understand these results even after careful scrutiny of the fopen() manual page, please visit http://www.php.net/support.php to find someone who might be able to help you.
 [2004-05-12 19:12 UTC] rc at opelgt dot org

 [2004-05-13 14:28 UTC] rc at opelgt dot org

 [2004-05-13 15:19 UTC] rc at opelgt dot org
Yes, my sent script runs identically for all modes under 
Linux and MacOSX.
Its different among the modes.

The mode options in fopen() for my understanding should 
have only effect
for the start: position of pointer, content of file, 
file creation if nessessary or not.
Sure, read or write or both ways of access should remain 
until fclose(). ;-)

'r' and 'w' need clearstatcache() but 'a' doesnt.

That is the unexpected and in the manual not mentioned 
difference.
 [2005-02-03 05:05 UTC] sniper@php.net
reclassified

 [2005-03-15 14:24 UTC] vrana@php.net
Please tell us what exactly is not documented. In my eyes, everything works exactly as described on fopen page, mainly in the table "A list of possible modes for fopen() using mode".
 [2005-03-23 01:00 UTC] phpdoc at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-03-23 11:53 UTC] rc at opelgt dot org
I have written all things that should be mentioned.

Please read it carefully and if you do not understand 
it, ask me again ;-)
 [2005-03-24 16:09 UTC] vrana@php.net
Tell us what's wrong or missing mainly in the table "A list of
possible modes for fopen() using mode". The behavior of the modes is explained well there IMHO.
 [2005-04-01 01:00 UTC] phpdoc at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-04-09 02:10 UTC] rc at opelgt dot org
Which language do you prefer: english or Deutsch?
 [2005-04-13 09:16 UTC] vrana@php.net
Guess! Come on guy, if you want to help us to fix the docs, write something meaningful. This bug fell twice to the state No Feedback, you reopened it twice and now you are asking what's the preferred language???

P.S. English is the preferred language.
 [2005-04-21 01:00 UTC] phpdoc at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2005-04-29 12:49 UTC] techtonik@php.net
To resume.. 

First is bug #32889 : ftruncate doesn't move the file pointer. After file is truncated file pointer is still at 11th position and if you comment first rewind you'll get: 
- in "r+" mode 15 bytes size file
- in "a+" mode filesize == 5 bytes
So, in append mode PHP makes additional fseek to the end of file. Seems logical to me if the same thing will be done in ftruncate.

Next bogus moment in this example is filesize() function - size of the file grows due to the previous bug, but filesize() cache isn't updated. That's why last fread in r+ mode doesn't return newly written string - it reads only first 10 empty bytes occurred after write operation beyond the EOF, while actual content is at bytes 11-15.

Blank output with "w+" mode is documented - this mode erases all previous contents, so there is nothing to read.

 [2005-04-29 16:21 UTC] vrana@php.net
Thus everything is/was already documented.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 18 05:03:21 2014 UTC