Req #54902 [PATCH]: fseek inconsistencies with large (>2GB) files

From: Date: Mon, 31 Aug 2020 08:32:02 +0000
Subject: Req #54902 [PATCH]: fseek inconsistencies with large (>2GB) files
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228804@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=54902&edit=1

 ID:                 54902
 Patch added by:     cmb@php.net
 Reported by:        zingaburga at hotmail dot com
 Summary:            fseek inconsistencies with large (>2GB) files
 Status:             Assigned
 Type:               Feature/Change Request
 Package:            Filesystem function related
 Operating System:   Windows 7
 PHP Version:        5.3.6
 Assigned To:        cmb
 Block user comment: N
 Private report:     N

 New Comment:

The following pull request has been associated:

Patch Name: Fix #54902: fseek inconsistencies with large (>2GB) files
On GitHub:  https://github.com/php/php-src/pull/6055
Patch:      https://github.com/php/php-src/pull/6055.patch


Previous Comments:
------------------------------------------------------------------------
[2020-08-14 14:20:06] cmb@php.net

The following patch has been added/updated:

Patch Name: position-no-overflow
Revision:   1597414806
URL:        https://bugs.php.net/patch-display.php?bug=54902&patch=position-no-overflow&revision=1597414806

------------------------------------------------------------------------
[2020-08-14 14:19:40] cmb@php.net

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
nowadays.

[1] <https://github.com/php/php-src/blob/php-7.3.21/main/streams/streams.c#L1286-L1291>

------------------------------------------------------------------------
[2011-05-22 05:50:22] 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.

http://pastebin.com/xWiQxgSB

------------------------------------------------------------------------
[2011-05-22 05:24:38] zingaburga at hotmail dot com

Description:
------------
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: http://windows.php.net/download/

See example script [ http://pastebin.com/Zb0vRgWX ] 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 >_>)



------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=54902&edit=1


Thread (5 messages)

« previous php.bugs (#228804) next »