ncheck -s

[Rick Ace]

In article <5552 at sdcrdcf.sm.unisys.com>, eggert at sundae.sm.unisys.com (Paul Eggert) writes:
> Guy Harris writes that "ncheck", both on S5R3 and 4.3BSD,
> has an "-s" flag to look for both suid-files and special device files.
> He also writes "I suspect it may do so faster than, say, 'find'."
> 
> On a Sun-3/160 fileserver under SunOS 4.0, I tried "ncheck -s".
> Sometimes it dumped core.  Sometimes it silently missed files.
> I persevered until I found a filesystem where it operated correctly.
> It took 25% more wallclock time than "find", and 60% more user+system CPU time.
> Beware "ncheck -s".

ncheck (when it works properly) is an efficient tool for scanning a
filesystem.  The 4.2bsd version of ncheck, however, suffered from some
problems.  The most serious of these, I recall, was an error in the
logic of a routine that read directory blocks, causing
	1) a performance problem (the same directory block was being
	   re-read unnecessarily), and
	2) incorrect behavior on directories exceeding a certain length
	   (ncheck would simply not report some filenames that did
	   indeed exist within the filesystem).
>From the symptoms you described, it sounds as though the ncheck
you're running might have this bug (this is very plausible since
SunOS was derived from 4.2bsd).

(Another bug appeared in the code that read the superblock; the code
read 8192 bytes into a "struct fs", which is approx. 1300 bytes long,
overwriting whatever data structure(s) the loader happened to place
immediately after the "struct fs" in memory.  This bug was not the
killer, though.)

Rick Ace
Pixar
3240 Kerner Blvd, San Rafael CA 94901
...!{sun,ucbvax}!pixar!rta