PHP does not currently support LFS.
This is something to be addressed in PHP 5.1

Well, looks like it will be fixed in 6.x instead.

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.

You might like to try the following patch:

http://news.php.net/php.internals/32767

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!

See also bug #48099 (NFS mounts misbehave also without the compile 
flags..)

And bug #45040

Please see fix in http://bugs.php.net/bug.php?id=48886

The latest patch for this:

  http://www.php.net/~wez/lfs.diff

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)

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 !

@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)

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

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.

This is no longer applicable.