|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #54902 fseek inconsistencies with large (>2GB) files
Submitted: 2011-05-22 05:24 UTC Modified: 2020-10-06 13:38 UTC
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: zingaburga at hotmail dot com Assigned:
Status: Open Package: Filesystem function related
PHP Version: 5.3.6 OS: Windows 7
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: zingaburga at hotmail dot com
New email:
PHP Version: OS:


 [2011-05-22 05:24 UTC] zingaburga at hotmail dot com
Firstly, I'm aware that fseek/ftell doesn't necessarily work correctly with >2GB files with 32-bit PHP due to integer range constraints, however, fseek operates rather inconsistently when passing 2GB, which would be nice if fixed (note that I've put this as a feature request, as it's a nice to have, and unsure if you'd classify this as a bug).

I'm using the 32-bit Windows build from here:

See example script [ ] with comments for more info.
I haven't looked at PHP's source code, but from the behaviour of the script, I'm guessing that fseek does some checks, and because it's overflowing, it won't allow certain operations.  I'm not sure about the weird 8192 byte limit though.
As fread allows overflows, would it be possible to allow fseek to overflow too?

(PS first time I've submitted a "bug" - I hope I've done it correctly >_>)


position-no-overflow (last revision 2020-08-14 14:20 UTC by

Add a Patch

Pull Requests

Pull requests:

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2011-05-22 05:50 UTC] zingaburga at hotmail dot com
If you're wondering, I'm using the following function to try to get around the fseek limitations.  It works, but it's really slow for large seeks.  If the 8KB limitation could be lifted, then this function could be serveral times faster.
 [2020-08-14 14:19 UTC]
Ugh, that is indeed ugly.  One way to fix this inconsistency would
be to avoid the stream.position to overflow (see the attached
position-no-overflow patch, which doesn't cater to writing,
though).  That would make the pastebin example to behave
reasonably.  However, that also would prohibit to read beyond the
2GB limit, so would likely break working code, and remove a
basically working feature.

Other than that, we could make the stream.position unsigned.  That
still would cause issues, because the stream layer converts
SEEK_CUR seeks to SEEK_SET[1] to cater to stream.position which is
not necessarily what ftell() would report (if the stream even
supports something like ftell()).  However, fseek() (or rather
lseek() which is used internally) expect signed offsets, so we
still couldn't seek beyond the 2GB limit – unless we'd rely on
large file support.  Not sure if that would be worth the trouble

[1] <>
 [2020-08-14 14:20 UTC]
The following patch has been added/updated:

Patch Name: position-no-overflow
Revision:   1597414806
 [2020-08-18 15:53 UTC]
-Assigned To: +Assigned To: cmb
 [2020-08-31 08:32 UTC]
The following pull request has been associated:

Patch Name: Fix #54902: fseek inconsistencies with large (>2GB) files
On GitHub:
 [2020-10-06 13:38 UTC]
-Status: Assigned +Status: Open -Type: Feature/Change Request +Type: Documentation Problem -Assigned To: cmb +Assigned To:
 [2020-10-06 13:38 UTC]
I think we should leave that as is, but document the behavior.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Jun 26 07:05:44 2022 UTC