Xref: utzoo comp.protocols.nfs:771 comp.unix.i386:3573
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!rutgers!mcdchg!laidbak!daveb
From: daveb@i88.isc.com (David G. Burton)
Newsgroups: comp.protocols.nfs,comp.unix.i386
Subject: Re: statbug.c: Spot a BUG with NFS stat() - please try this. Esp 386/ix!
Keywords: stat, nfs, svr3, i386
Message-ID: <1990Mar14.192005.25313@i88.isc.com>
Date: 14 Mar 90 19:20:05 GMT
References: <638@hades.OZ>
Sender: usenet@i88.isc.com (Usenet News)
Organization: Interactive Systems nee Lachman Associates
Lines: 34

In article <638@hades.OZ> greyham@hades.OZ (Greyham Stoney) writes:
| SYSTEM: ISC 386/ix 2.0.2 NFS
| PROBLEM: stat() library function returns a garbage st_dev field for NFS mounted
| 	files.
| ... 
| TEST:	The program below (statbug.c), when run with a single filename argument
| 	will see if the st_dev number returned by stat() is positive.
|	... 
| 	On my system the st_dev number returned is negative; clearly a load of
| 	garbage. ...
| 
| Please tell me if your system fails this test.
| [ program to check if stat().st_dev < 0 deleted ]

NFS implementations derived from Lachman NFS *should* fail this "test".
The test is inappropriate.  As explained in an earlier post, SVR3.x
determines the remote-ness of a file by a negative st_dev. The -local
option of find(1) reports true if ~st_dev is less than zero (i.e. if
st_dev is positive, it's local). The NFS dependent stat code gets st_dev,
then complements the MSB so that find(1) works properly. Note that the
stat(2) man page is not completely accurate when it states for st_dev,
"No other meaning is associated with this value." Also heed the caveat
on the ustat(2) man page - use statfs(2) instead.

| 	... It may also be positive and a load of garbage however. A very
| 	big positive number probably looks sus.

On an i386 NFS client, the only way for st_dev to come out positive would
be for bmajor(nfsd_major_number) > 127. This is not possible.

-- Dave Burton
--
Dave Burton
uunet!ism780c!laidbak!daveb