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