php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #38758 fseek returns false if offset is over 10GB (10737418239 bytes)
Submitted: 2006-09-09 00:42 UTC Modified: 2006-09-09 10:41 UTC
From: geoffrey at google dot com Assigned:
Status: Not a bug Package: Filesystem function related
PHP Version: 5.1.6 OS: Redhat Linux 2.4.22
Private report: No CVE-ID: None
 [2006-09-09 00:42 UTC] geoffrey at google dot com
Description:
------------
fseek returns false if offset is over 10GB (10737418239 bytes). This could be an underlying problem with llseek. 

I'm running php 5.1.6. my config line:

CFLAGS="-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ./configure

Using stock php.ini-dist



Reproduce code:
---------------
#!/usr/local/src/php-5.1.6/sapi/cli/php -q
<?
$file = "bigfile"; // file is 20GB large
$fp = fopen($file, 'r');

fseek($fp, 10737418239, SEEK_CUR);

$line = fgets($fp, 512);
echo $line; // prints the correct line
echo ftell($fp); // returns -214748361201

rewind($fp);

fseek($fp, 10737418240, SEEK_CUR);

$line = fgets($fp, 512); 
echo $line; // prints the first line of the file
echo ftell($fp); // returns 54 which is the strlen() of line 1


Expected result:
----------------
both fseeks should be 1 byte apart and should return successful. Both fgets should return the same data only 1 byte apart. ftell should return 10737418239 for the first run and 10737418240 for the second. 

Actual result:
--------------
The first fseek is successful and fgets returns the correct bytes. The second fseek (1 byte beyond 10GB) fails and returns bytes at the begining of the file. 

ftell also seems broken as it returns -214748361201 in the first run. It returns the correct offset in the second because fseek fails and sets the offset to the begining of the file.

strace output:

<snip>...
lstat64("bigfile", {st_mode=S_IFREG|0666, st_size=20304186228, ...}) = 0
open("bigfile", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0666, st_size=20304186228, ...}) = 0
_llseek(3, 0, [0], SEEK_CUR)            = 0
_llseek(3, 2147483647, [2147483647], SEEK_SET) = 0
read(3, "<snip>"..., 8192) = 8192
write(1, "<snip>"..., 37,<snip>
) = 37
write(1, "-2147483612", 11-2147483612)             = 11
_llseek(3, 0, [0], SEEK_SET)            = 0
_llseek(3, 18446744071562067968, 0xbfffcdf0, SEEK_SET) = -1 EINVAL (Invalid argument)
read(3, "<snip>"..., 8192) = 8192
write(1, "<snip>"..., 54<snip>
) = 54
write(1, "54", 254)                       = 2
close(3)                                = 0
close(0)
...</snip>
Geoff

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-09-09 06:27 UTC] judas dot iscariote at gmail dot com
AFAIK, LFS support is not working properly and IIRC last time I saw developer response, this is scheduled to be fixed only in PHP6.

somebody can correct me If I wrong.
 [2006-09-09 10:41 UTC] tony2001@php.net
Integer is still limited, even if you use _FILE_OFFSET_BITS.

 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue May 17 06:05:44 2022 UTC