Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 4 product line. The current stable release is 4.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 163365

Summary:

Apache fails on directory listing of files from MS NFS

Product:

Red Hat Enterprise Linux 4

Reporter:

Bastien Nocera <bnocera>

Component:

apr

Assignee:

Joe Orton <jorton>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

medium

Docs Contact:

Priority:

medium

Version:

4.0

CC:

jakub

Target Milestone:

---

Target Release:

---

Hardware:

All

OS:

Linux

Whiteboard:

RHEL4U3NAK

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-10-27 16:20:24 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
test-apr3.c	none

Description Bastien Nocera 2005-07-15 14:25:58 UTC

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.

Comment 1 Bastien Nocera 2005-07-15 14:25:58 UTC

Created attachment 116801 [details]
test-apr3.c

Comment 2 Bastien Nocera 2005-07-18 10:30:05 UTC

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

Comment 3 Joe Orton 2005-07-18 12:52:10 UTC

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

Comment 5 Thomas Uebermeier 2005-07-20 10:04:13 UTC

Summary: basically no, all inode numbers are within (signed) 32bit

Comment 11 Jakub Jelinek 2005-07-21 09:03:03 UTC

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.

Comment 22 RHEL Program Management 2006-08-18 17:33:20 UTC

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.