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