php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #76995 fseek() breaks reading in read/append (a+) mode
Submitted: 2018-10-10 14:58 UTC Modified: 2018-10-10 16:08 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: miloslav dot hula at gmail dot com Assigned:
Status: Open Package: Streams related
PHP Version: 7.3.0RC2 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: miloslav dot hula at gmail dot com
New email:
PHP Version: OS:

 

 [2018-10-10 14:58 UTC] miloslav dot hula at gmail dot com
Description:
------------
URL in a test script shows, how fseek() in 'a+' mode breaks contents reading.

Documentation of fopen() says, that fseek() is OK, but documentation of fseek() says, that seeking in a+ mode is bad idea.

In documentation of fopen():

a+ - Open for reading and writing; place the file pointer at the end of the file. If the file does not exist, attempt to create it. In this mode, fseek() only affects the reading position, writes are always appended.

In documentation of fseek():

If you have opened the file in append (a or a+) mode, any data you write to the file will always be appended, regardless of the file position, and the result of calling fseek() will be undefined.

Test script:
---------------
https://3v4l.org/gTXsR


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-10-10 15:03 UTC] spam2 at rhsoft dot net
but what is the bug?

> seeking in a+ mode is bad idea
> and the result of calling fseek() will be undefined

undefined is what it is - undfined - therw is no right/wrong for undefined
 [2018-10-10 15:07 UTC] miloslav dot hula at gmail dot com
At least, documentation is misleading. "a+ mode is for reading/append". How can one read from file, when cannot seek?

Could be clearer with: "only appended data can be read, seeking not supported"
 [2018-10-10 15:11 UTC] miloslav dot hula at gmail dot com
Or: "In this mode, fseek() only affects the reading position". Sound like positive claim.
 [2018-10-10 16:07 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2018-10-10 16:07 UTC] requinix@php.net
Unfortunately this really is one of those "undefined behavior" situations, and PHP isn't the one responsible for it.

Look at the fopen(3) docs on Linux: https://linux.die.net/man/3/fopen
> Reads and writes may be intermixed on read/write streams in any order. Note
> that ANSI C requires that a file positioning function intervene between output
> and input, unless an input operation encounters end-of-file. (If this condition
> is not met, then a read is allowed to return the result of writes other than
> the most recent.) Therefore it is good practice (and indeed sometimes necessary
> under Linux) to put an fseek(3) or fgetpos(3) operation between write and read
> operations on such a stream. This operation may be an apparent no-op (as in
> fseek(..., 0L, SEEK_CUR) called for its synchronizing side effect.
 [2018-10-10 16:08 UTC] requinix@php.net
-Status: Not a bug +Status: Open -Type: Bug +Type: Documentation Problem
 [2018-10-10 16:08 UTC] requinix@php.net
And seconds after I hit Submit, I realize that documenting append mode's fseek quirks would be a good idea.
 [2023-05-13 12:02 UTC] cynthiamarshal0010 at gmail dot com
To address the doc bug where fseek() breaks reading in read/append (a+) mode, it's important to understand the behavior of fseek() in that mode and how to correctly position the file pointer for reading. Here's an explanation and solution to update the documentation:

Explanation:
In the a+ mode, when you use fseek() with a positive offset, it is expected to move the file pointer to that offset from the beginning of the file. However, in certain implementations, fseek() may not work as expected in a+ mode and instead positions the file pointer relative to the current end of the file. This behavior can lead to unexpected results when trying to read from the file.

Solution:
To correctly position the file pointer for reading in a+ mode, you should use fseek() with a negative offset relative to the end of the file. Here's an example of how to update the documentation to reflect this:

vbnet

When using `fseek()` in read/append (`a+`) mode, it's important to note that its behavior may vary depending on the implementation. In some cases, `fseek()` may not correctly position the file pointer for reading. To ensure proper positioning, follow the recommended approach below:

To move the file pointer to a specific position from the end of the file, use a negative offset with `fseek()`. For example, to move the file pointer to the last 100 bytes of the file:

   fseek(file, -100, SEEK_END);

This ensures that the file pointer is correctly positioned for subsequent read operations.

Please note that this workaround may not be necessary in all implementations of the C standard library. It's recommended to test and verify the behavior of `fseek()` in your specific environment to ensure compatibility and consistent results.

By providing this updated information, users will be informed about the potential issue with fseek() in a+ mode and the recommended approach to correctly position the file pointer for reading. (https://dgmeportal.live/)github.com
 [2023-12-10 04:21 UTC] sincerelyjulie0 at gmail dot com
position the file pointer for reading.
 [2024-01-10 13:52 UTC] riz dot ali0001 at gmail dot com
The issue highlighted in the test script relates to the use of fseek() in 'a+' mode, which appears to disrupt content reading. This seems to stem from conflicting information in the documentation. While the fopen() documentation indicates that fseek() can be used in 'a+' mode to adjust the reading position (with writes always being appended), the fseek() documentation contradicts this by stating that using fseek() in append mode ('a' or 'a+') can lead to undefined behavior. This discrepancy suggests a need for clarification in the documentation to ensure proper usage and avoid potential
 issues in file handling
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Nov 05 23:01:28 2024 UTC