Directory listing the root directory of an NFS mount from an MS server in Apache shows up as empty, as if with no (not even '..') directories. ls on the same directory works. The attached test case, which uses APR's API to read the directory listing, as well as readdir and readdir_r shows the problem: - APR fails, with an EOVERFLOW error - readdir works - readdir_r (using code similar to what APR uses) works If the #defines for LFS support are removed in the test case, readdir and readdir_r will fail. So APR needs to be recompiled with LFS support (so that the testcase above uses readdir64 instead of readdir) for the listing to work on this NFS mount.
Created attachment 116801 [details] test-apr3.c
I've tried recompiling apr with large readdir support, and it would basically break ABI. From /usr/include/bits/dirent.h: struct dirent { #ifndef __USE_FILE_OFFSET64 __ino_t d_ino; __off_t d_off; #else __ino64_t d_ino; __off64_t d_off; #endif unsigned short int d_reclen; unsigned char d_type; char d_name[256]; /* We must not include limits.h! */ }; #ifdef __USE_LARGEFILE64 struct dirent64 { __ino64_t d_ino; __off64_t d_off; unsigned short int d_reclen; unsigned char d_type; char d_name[256]; /* We must not include limits.h! */ }; #endif
To follow up some off-line discussion: I'm not clear about exactly why this happens. It appears the case being hit here may be glibc returning EOVERFLOW because the inode number cannot be stored in a struct dirent with a 32-bit d_ino field. Can you confirm whether there are files with inode numbers > 2^31 in this directory? (e.g. using "ls -lia")
Summary: basically no, all inode numbers are within (signed) 32bit
4294967039 certainly doesn't fit into (signed 32-bit) d_off, so glibc behaviour is correct. Now, the bug is either on the MS side or in the kernel, depending on whether the actual values are going over the wire as 32-bit or 64-bit values. If as 32-bit values, then kernel must sign extend them when getdents64 is called, because it is storing a 32-bit value into signed off64_t.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.