SGI csh glob vs. NeXT NFS (SGI 3.3 client, NeXT 1.0 server)

[Stuart Levy]

We're finding that csh (and tcsh) file pattern globbing fail on our SGI 3.3
and 3.3.1 machines when applied to an NFS-mounted NeXT (1.0) file system.
"echo *" yields "echo: No match", attempts at file-completion just beep, etc.

I'd run into this once before (under SGI 3.2), just now tracked it down, and
am reporting it here for SGI & NeXT's benefit and in case it's bitten
someone else.

Cases where this *doesn't* happen, i.e. globbing works properly:
  - SGI csh globbing works fine on local file systems,
	and on fs's NFS-mounted from Sun servers.
  - SGI ls, sh and ftpd globbing work fine on all file systems.
  - Compiling the Berkeley glob.c from uunet, which uses readdir(),
	yields something that works on all file systems.
  - Suns mounting the same NeXT fs can glob on it too.

Poking at the NFS protocol messages, it looks like SGI's csh is reading
directories in 512-byte chunks, while the library readdir() reads in 8K units.

Apparently 512 bytes is too short for the NeXT; its NFS server responds with
EINVAL (invalid argument).  The SGI kernel doesn't report the error to csh,
just gives a 5-byte (!) result from the getdents() system call which csh
interprets as an empty directory.

	Stuart Levy, Geometry Group, University of Minnesota
	slevy at geom.umn.edu