Bug 648 - cannot list directory entries fm NFS mounted IRIX 6.3 (xfs)
Summary: cannot list directory entries fm NFS mounted IRIX 6.3 (xfs)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 5.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1998-12-29 19:49 UTC by lcano
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-07-28 05:23:50 UTC

Attachments (Terms of Use)

Description lcano 1998-12-29 19:49:46 UTC
Used the following code to troubeshoot:

#include <dirent.h>
#include <stdlib.h>

main(int argc, char  **argv){
   struct dirent **namelist;
   int n;

   if (argc != 2) {
     printf("usage: %s dirname\n", argv[0]);

   printf("%s: started with argument %s\n", argv[0],

   n = scandir(argv[1], &namelist, 0, alphasort);
     if (n < 0)
       while(n--) printf("%s\n", namelist[n]->d_name);

The above code produces the following results when ran
against a nfs mounted filesystem, exported from a HPUX 10.20

lcano/t /scott
/home/lcano/t: started with argument /scott

Which is correct. Produces the following when ran against a
irix 6.3 (I'm assuming that 6.4 and 6.5 would produce the
same results, but I didn't check).

lcano/t /scott
/home/lcano/t: started with argument /scott
scandir: Invalid argument

Which did not work. Also tried it on a IRIX 5.1 system and
it worked.

Analyzed the code through:

59 bytes = __getdirentries (dirp->fd, dirp->data, maxread,

79  retval = __getdents (fd, (char *) kdp, red_nbytes);

and kdp->d_off seems invalid for irix 6.3 but ok for hpux
10.20 and irix 5.1:

-- irix 6.3

(gdb) p *kdp
$145 = {d_ino = 128, d_off = 5934, d_reclen = 12,
  d_name =

ls -al /scott
total 9
drwxr-xr-x   5 root     root           48 Dec 29  1998 .
drwxr-xr-x  30 root     root         1024 Dec 29 04:18 ..
drwxr-xr-x  51 1082     2008         4096 Dec 29 07:28
drwxr-xr-x   8 1082     2008           98 Dec 17 12:02 sj1
drwxr-xr-x  14 1082     2008         4096 Dec 17 11:07 sj2

-- irix 5.1

(gdb) p *kdp
$146 = {d_ino = 2, d_off = 1, d_reclen = 12,
  d_name =

ls -al /scott
total 16
drwxr-xr-x   5 root     root          512 Dec 29  1998 .
drwxr-xr-x  30 root     root         1024 Dec 29 04:18 ..
drwx------   2 root     root        10752 Apr 28  1997
drwxrwxr-x  19 1591     wd4          1024 Dec  8 22:40
drwxr-xr-x   3 1595     wd4           512 Apr 28  1997
-rw-r--r--   1 root     root          348 Dec 29  1997 test

-- hpux 10.20

(gdb) p *kdp
$148 = {d_ino = 2, d_off = 12, d_reclen = 12,
  d_name =

ls -al /scott
total 11
drwxr-xr-x   7 root     root         1024 Dec  1  1997 .
drwxr-xr-x  30 root     root         1024 Dec 29 04:18 ..
drwxr-xr-x   9 1686     wd4          4096 Dec 29  1998
drwxr-xr-x   2 root     root         8192 Aug 30  1993
drwxr-xr-x   2 1318     wd4            24 Sep 20  1993
drwxr-xr-x  18 1611     2008         2048 Nov 24 15:54 nawbk
drwxr-xr-x  19 1674     2008         1024 Sep 22 08:05

In readdir _DIRENT_HAVE_D_RECLEN is defined and thus uses
the value for dp->d_off to set dirp->filepos.

My appologizes for being so wordy with this description.


Luis Cano

Comment 1 lcano 1998-12-29 19:57:59 UTC
The #includes for the test code should be:

#include <dirent.h>
#include <stdlib.h>

Sorry for the omission.


Comment 2 lcano 1998-12-29 20:02:59 UTC
The greater and less than sign, part of the #include statement is not
carrying over to the "view bug". Once again, the includes should be:

#include dirent.h
#include stdlib.h

and the greater and lesser than signs inserted.

I need to read the FAQ.


Comment 3 Chris Siebenmann 1999-02-15 08:01:59 UTC
The root cause of this problem is that the Linux kernel (at least
in the 2.0.* series) cannot handle NFS v2 directory cookies that
have their high bit set (NFS v2 directory cookies are nominally
unsigned 32-bit blobs). This is a difficult problem to solve for
real because the user/kernel interface to deal with them is lseek(),
which only deals with positive signed 32-bit integers and thus will
never be able to cope well with such cookies.

 It is possible to create a somewhat gory kernel hack that will
let glibc et all do a telldir() (but not a seekdir()) on such
cookies. This keeps glibc's readdir() happy.

 I have such a patch if people want a copy; send email.

------- Email Received From  Luis Cano <lcano.gov> 02/22/99 10:57 -------

Comment 4 Preston Brown 1999-03-22 18:55:59 UTC

Comment 5 Michael K. Johnson 1999-04-09 21:41:59 UTC
I believe that this is worked around in the 2.2 kernel, but I don't
expect that we will release a 2.0 kernel with a workaround for this
as an errata upgrade for 5.2.

If you like, you might try our unofficial 2.2 kernel upgrade and
see if it works better for you.

Alternatively, if the "somewhat gory" kernel hack from cks worked
for you, please note it here.

Comment 6 Chris Siebenmann 1999-04-27 20:24:59 UTC
This bug seems to still be present in the 2.2.* kernel series
(I don't have a Rawhide/Starbuck/6.0 machine handy, but I tried
it on a 2.2.6-ac2 kernel on a RH 5.2 install, and it had the same

Comment 7 Cristian Gafton 1999-06-17 16:32:59 UTC
Alan, do you have any clue on this one?

Comment 8 Alan Cox 1999-06-17 20:26:59 UTC
Two suggestions. Firstly there is an Irix option to use 32bit
cookies. Check the irix docs - I no longer have an indy so I cant
check easily here what it is.
Xecondly get me a tcpdump of the failing case. The only problem I know
about for Irix is duplicated directory cookies. That would be very
different to what you see.

Check the tcpdump docs btw  you can ask it to capture all of the
packet and decode higher protocols the trace then has NFS data in it
which I can work from.


Comment 9 Cristian Gafton 1999-07-28 05:23:59 UTC
This could be very well a kernel problem. Does a later release of the
kernel (2.2.x) fixed the problem? Is it still true for a 6.0 system
running glibc-2.1.1 or later?

Please reopen if the problem  still persists.

Note You need to log in before you can comment on or make changes to this bug.