statbug.c: Spot a BUG with NFS stat() - please try this. Esp 386/ix!

David G. Burton daveb at i88.isc.com
Thu Mar 15 05:20:05 AEST 1990


In article <638 at hades.OZ> greyham at 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



More information about the Comp.unix.i386 mailing list