Hi,

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

Heh, heh. I know the feeling. At one time I had an even stronger opinion
that basically stated that "native BSD uses 64bit opaque offsets and that's
all the NFS client should support", which breaks pretty well all the
compatibility cases.

Unfortunately I think Linux compatibility has gone from "nice to have" to
"an essential feature", since a lot of companies are starting to ship Linux
binaries (such as Java JDK, etc.) and not doing other ports. (Around here
I've been a long time BSD guy, but the only BSD machines I run are NFS
servers. Everything else (about 300 machines) runs Linux and/or Windoze.)

Sadly, the only "fix" I can think of is for nfs_readdir() to hold onto all
directory offsets for open directories and then generate a "fake 32/64bit byte
offset that monotonically increases by the size of data returned" that's
returned through nfs_readdir(). Ugly, but it's the only way
I can see that will make Linux binaries work correctly?

fyi: I am just testing the server side of my nfsv4 code against the Univ. of
     Michigan client, so I might have a snapshot with V4 in it, later this
     summer. The code is pretty well vanilla BSD, so it avoids the above and
     will not be ready for public consumption for quite some time, but it is
     slowly getting there. (It looks like it'll be a while before other
     mature NFS V4 implementations hit the street, anyhow.)

     I have no idea if NetBSD is interesting in adopting it, but I'll
     email this list when a snapshot is available, just in case.