On Fri, May 24, 2002 at 11:53:59AM +0200, Jaromir Dolecek wrote:
> The cookies returned by our nfs_readdir() are in netowork byte
> order, so instead of 12, 24, 36 ... the values provided in the
> array are seen like 201326592, 402653184, etc on i386.  These values
> are directly passed via d_off member of the structure returned to
> linux userland. Now, glibc checks the d_off value and stops reading
> once entry's d_off is smaller than previous entry. Due to byteswapping,
> this eventually happens, and result is that glibc ends processing
> the returned directory data prematurely.
> 
> Now, I'm not too sure what to do. The d_off _has to_ be valid
> directory offset, glibc is using that in seekdir() and telldir(),
> so it can't be fabricated e.g. as index value or something.
> It has to be valid parameter for lseek(), too.
> 
> My opinion is that nfs_readdir() should byteswap the cookies as
> appropriate. nfs_readdir() is called (via VOP_READDIR()) by client
> code only, it's not used by the NFS server code as far as I can tell.
> As far as I can tell, the other emulations using/setting d_off
> should have this problem too. I've checked that if I convert
> the cookies from network to host byte order, the problem with listing
> NFS directory contents is gone (i.e., no loop and all entries
> are displayed).

nfs_readdir should *not* be changed, I will not allow it in fact.

The directory 'offset' in NFS is a cookie, it is an opaque
entity. You may not interpret its value. Historically, some
implementations did do this for NFSv2, but the cookie became
64 bits large in NFSv3, making this hazardous. Furthermore,
the value is entirely determined by the server, so messing
around with it on the client is no guarantee for anything
to work.

Linux (and glibc) messes this up. Which is why Linux has/had problems
with Irix servers, that actually use opaque 64bit cookies (which
is perfectly legitimate according to the spec). I think they only
recently fixed it in the client kernel side. I fixed it for NetBSD
in 1996. If you search the tech-kern archives for a message
with subject 'NFS cookie jar' by me, you'll find a description
of the problem and how it was fixed.

- Frank

-- 
Frank van der Linden                           fvdl@wasabisystems.com
======================================================================
Quality NetBSD CDs, Support & Service.   http://www.wasabisystems.com/