Xref: utzoo comp.sys.sgi:5959 comp.sys.next:7976
Path: utzoo!attcan!uunet!crdgw1!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!srcsip!msi-s0.msi.umn.edu!cs.umn.edu!news
From: slevy@geom.umn.edu (Stuart Levy)
Newsgroups: comp.sys.sgi,comp.sys.next
Subject: SGI csh glob vs. NeXT NFS (SGI 3.3 client, NeXT 1.0 server)
Message-ID: <1990Sep26.003327.9076@cs.umn.edu>
Date: 26 Sep 90 00:33:27 GMT
Sender: slevy@geom.umn.edu
Organization: Geometry Group, University of Minnesota
Lines: 26
Nntp-Posting-Host: poincare.geom.umn.edu

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@geom.umn.edu