ID: 33872
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Debian Woody
PHP Version: 4.3.11
New Comment:
Apologies, I did not originally realize that these #defines
were the same as LFS support, as the original problematic
cause affected *all* files across an NFS share, and not just
the 2+ GB ones.
Previous Comments:
------------------------------------------------------------------------
[2005-07-26 21:57:50] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #27792.
------------------------------------------------------------------------
[2005-07-26 21:01:24] gabe at mudbugmedia dot com
Description:
------------
When compiling PHP on Debian-woody, the readdir()
functionality was not overriden through configuration
definitions (such as -D_FILE_OFFSET_BITS=64) to use the 64
bit readdir function.
This leads to the failure of a program to read a directory
from an NFS share which forces 64 bit mode, such as an NFS
share from MacOSX 10.4+ and IRIX. In such cases the readdir
() function will only return two directory entities, '.' and
'..'. Examining the strace output of this process shows:
open("/tmp/files", O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2ebf8000
write(1, "dir opened fine\n", 16dir opened fine
) = 16
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2168
_llseek(3, 2, [2], SEEK_SET) = 0
write(1, ".\n", 2.
) = 2
write(1, "..\n", 3..
) = 3
getdents64(0x3, 0x839ed80, 0x2000, 0x1d) = 2120
close(3) = 0
Note that after the getdents(), _llseek() is used to rewind
it, which should not happen. In a program compiled properly
to use readdir64():
open("/tmp/files", O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=2278, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
brk(0x805a000) = 0x805a000
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 2168
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
3), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0) = 0x2579c000
write(1, ".\n", 2.
) = 2
write(1, "..\n", 3..
) = 3
write(1, ".DS_Store\n", 10.DS_Store
) = 10
write(1, ".TemporaryItems\n", 16.TemporaryItems
) = 16
<cut>
write(1, "Zeitzer\n", 8Zeitzer
) = 8
getdents64(0x3, 0x8055ff8, 0x2000, 0x2) = 0
close(3) = 0
No _llseek() is used.
This inability for 64 bit NFS data to be read through a 32
bit readdir() is most likely due to a bug in the kernel, but
has not be addressed (this has not been confirmed, I read
this at kerneltrap but lost the link) because 32 bit readdir
() is supposed to be deprecated. Reguardless what causes
the bug, PHP should detect for this and set the appropriate
#define in it's configuration file. Several programs,
including bash, ls, and perl, all do this work around.
Reproduce code:
---------------
Failed sample used in the above strace:
<?php
$dir = '/tmp/files';
if ($handle = opendir($dir)) {
echo "dir opened fine\n";
while (false !== ($file = readdir($handle))) {
echo "$file\n";
}
closedir($handle);
} else {
echo "could not open dir\n";
}
?>
Expected result:
----------------
Full directory content to be displayed
Actual result:
--------------
[EMAIL PROTECTED]:~$ php -f rd.php
dir opened fine
.
..
[EMAIL PROTECTED]:~$
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=33872&edit=1
