Bug#177135: File browsers browsing SGI served NFS directories don't display all directories.
On Fri, Jan 17, 2003 at 08:53:14PM +0800, P Hornby wrote:
> I have only been able to reproduce this for SGI NFS servers, using
> both Version 2 and 3 protocols.
You need to tell the NFS _server_ that you have "32 bit clients" (the
option, in /etc/exports, is called '32bitclients'). You also need to
patch the kernel of your clients using Trond's NFS patches[0]. If I'm
not mistaken, our precompiled kernels have some of these patches
already applied.
[0] http://www.fys.uio.no/~trondmy/src/
> On the linux side, my kernel is 2.4.19-rc2, but the problem presists
> across many kernels.
The problem has been there, like, forever. Trond has been maintining
these patches, like, forever.
> That it occurs in a variety of apps suggests a library somewhere that
> is not handling something stupid that the SGI is serving up as a
> directory listing.
The problem has to do with the size and uniqueness of the NFS cookies
the SGI server is (correctly) using. Both sides like to point their
finger to the other side...
> To add to the mystery, ls works fine. Solid as a rock, as is file IO
> etc to/from the server.
The problem has to do with the _names_ of the files in the directory
you are browsing and the order in which readdir is called (wrt... I
forgot what the other factor was -- it's been quite a while since the
last time I looked at this).
> libc6 is 2.3.1-9, but the problem has persisted through many versions
> of libc6. The problem pre-dates the move to gcc-3.2.2-0 on the
> current unstable branch.
Like I said, the problem has been there forever. It seems to also be
dependant on the phase of the moon on the day the C library was
compiled...
It is very annoying, since everything works fine most of the time, but
once the problem hits, it stays there.
The aforementioned patches fix other interaction problems with IRIX,
too.
--
Marcelo
Reply to: