php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27792 [PATCH] Functions fail on large files (filesize,is_file,is_dir,readdir)
Submitted: 2004-03-31 03:27 UTC Modified: 2013-09-12 22:13 UTC
Votes:288
Avg. Score:4.4 ± 0.9
Reproduced:239 of 249 (96.0%)
Same Version:100 (41.8%)
Same OS:120 (50.2%)
From: kode at kodekrash dot com Assigned:
Status: Open Package: Filesystem function related
PHP Version: 5.*, 6CVS (2009-04-30) OS: * (LFS)
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2004-03-31 03:27 UTC] kode at kodekrash dot com
Description:
------------
Error:
 (errno=75 - Value too large for defined data type)

Functions:
 is_file
 is_dir
 filesize

Premise:
 size of file is greater than 2GB.

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

I have been able to reproduce this error on 4 different PHP installations (all on RedHat 7.3 machines), using 12 different files for each test.

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

This bug has been submitted before, but is marked as BOGUS, which it is certainly not.

Reproduce code:
---------------
filesize( $fname );
or
is_file( $fname )
or
is_dir( $fname )

where filesize( $fname ) > 2GB

Expected result:
----------------
Function: filesize
Expected: numeric value matching size of file

Function: is_file
Expected: boolean value

Function: is_dir
Expected: boolean value

Actual result:
--------------
(errno=75 - Value too large for defined data type)

Patches

php551LFS.patch (last revision 2013-08-30 14:07 UTC) by mail dot pourri at laposte dot net)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-03-31 07:14 UTC] wez@php.net
PHP does not currently support LFS.
This is something to be addressed in PHP 5.1
 [2005-08-11 16:06 UTC] wez@php.net
Well, looks like it will be fixed in 6.x instead.
 [2005-10-24 21:16 UTC] hendersj at mindspring dot com
I have seen problems related to this both over NFS and using a local NSS filesystem with Novell Open Enterprise Server (Linux kernel, SLES 9 is where the package orginates).  The problem I have seen is more accurately described in bug 33872, which was flagged as a duplicate of this bug.

Bug 33872 describes a condition where readdir() returns only the entries "." and ".." (in my case just "." is returned) regardless of the permissions to the directory.  The same code run against a reiserFS partition works just fine.

I am running php 4.3.4; I have also seen it with PHP 4.2.2 when using an NFS server that has 64-bit cookie values.
 [2007-10-14 22:17 UTC] wez@php.net
You might like to try the following patch:

http://news.php.net/php.internals/32767
 [2008-12-05 17:28 UTC] aklmnop at gmail dot com
I had to change a couple more LVAL's to DVAL and RETURN_LONG to 
RETURN_DOUBLE after using the above patch, to make fseek(), fread(), 
ftell() and fwrite() work in PHP 5.2.4. This stuff is way too broken. 
Shamefully broken!
 [2009-04-30 19:45 UTC] jani@php.net
See also bug #48099 (NFS mounts misbehave also without the compile 
flags..)

 [2009-04-30 19:45 UTC] jani@php.net
And bug #45040
 [2009-07-11 13:40 UTC] mail dot pourri at laposte dot net
Please see fix in http://bugs.php.net/bug.php?id=48886
 [2009-09-14 08:59 UTC] jani@php.net
The latest patch for this:

  http://www.php.net/~wez/lfs.diff
 [2009-11-12 10:27 UTC] boite dot pour dot spam at gmail dot com
The patch from Wez doesn't work, as it assumes size_t are 64 bits, which is not the case, even when LFS is defined.

The patch from Mail Pourri works on 5.3.0 (I haven't tested in 5.3.1)
 [2011-01-05 04:46 UTC] marcb at voicemeup dot com
Is anyone able to confirm if this was fixed in any of the 5.X branch ?

This is a pretty stupid problem to have to deal with !
 [2012-08-09 13:28 UTC] adu at rdsor dot ro
@marcb

I tested it in "PHP 5.4.0 (cli) (built: Apr 12 2012 13:02:59)) on Ubuntu 12.04 kernel 3.0.0-19 i686" and the BUG is still here.

Reproduced code:
$fname = 'file_of_7GB';
var_dump(filesize( $fname ));
// PHP Warning:  filesize(): stat failed for file_of_7GB in php_bug_27792.php on line 4
// dumps bool(false)
var_dump(is_file( $fname ));
// dumps bool(false)
var_dump(is_dir( $fname ));
// dumps bool(false)


$fname = 'file_of_354MB';
var_dump(filesize( $fname ));
// dumps int(370336155)
var_dump(is_file( $fname ));
// dumps bool(true)
var_dump(is_dir( $fname ));
// dumps bool(false)
 [2013-05-29 09:57 UTC] Sjon at hortensius dot net
According to http://3v4l.org/sBClC; this is not a problem on a 64 bits linux 
machine (on any php version). I propose (since this bug obviously won't be fixed) 
to close this issue and tell people to use 64 bits machines instead of trying to 
get LFS support in PHP
 [2013-08-30 14:23 UTC] mail dot pourri at laposte dot net
This is the most absurd comment I've ever seen!
"The software does not work as expected, please fix your machine."

I've attached a new updated version of the patch against version 5.5.1
I've no time to backport the patch to any previous version, please be my guest if 
you need it.

Some comments about the patch:
1) Changes size_t to off_t at required places in the code (this will only work if 
the LFS mode is specified at compilation/configuration time, that is if you type 
"CFLAGS='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' ./configure --usual-args"

2) Pass all the tests that where passing without the patch

3) Fix a test that was failing without the patch (you can't mmap a pipe's file 
descriptor, the patch prevent doing so instead of failing at runtime) 

4) Returns a double when/where the file size/offset is larger than 2^32 bytes. 
This means that file with size up to 2^52 (the size of a double's mantissa) can 
now be used with PHP on 32 bits machine. This is not the plain 64 bits, but adding 
a new type to PHP for 64 bits integer would be a much larger work. For file 
size/offset below 2^32 bytes, the previous type (integer) is still used, so 
backward compatibility is kept. For file larger than 2^52 bytes, approximate 
values are used (this is still not an issue since reading/writing such file would 
still work since it's done in C) 

5) Loops on copy_stream/passthru until the complete stream is read, unlike the 
previous behavior of only reading up to the first 2GB of the file.

Let me know if it helps.
 [2013-09-12 22:13 UTC] nikic@php.net
-Status: Critical +Status: Open
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sun Apr 20 08:02:33 2014 UTC