Setting the record straight on SunOS 4.0 'fastfind'

[Guy Harris]

>I wrote this code years ago; it was actually part of BSD 4.2, but got lost
>in the shuffle at Sun when they went the SVID route.

4.2 or 4.3?  It was added into SunOS 3.2 when the 4.3BSD "find" stuff was
merged into the S5R2 "find" to make the 3.2 "find".  (I know that for a
fact; I did the merging.)

>Though undocumented in the manual page,

...because the claim that

	find <file>

will find all files whose names match "<file>" is an assertion about the
local system administrator's policy as much as it is a statement about the
behavior of "find"; Sun wasn't in a position to control the former,
especially given that the "fast find" stuff doesn't scale in an
immediately obvious way for NFS.  (Has anybody actually tried

	1) putting the appropriate "crontab" entry in on *all* machines
	   on a network with many diskless workstations

and

	2) changing "updatedb" not to stop at NFS mount points

If so, how much of a load does it impose?)

[[ Which is precisely why Sun neither documented fast find nor put
updatedb in crontab for their distributions.  --wnl ]]

It's also not clear how it should work if you use the automounter....

>Finally, the largest crime committed in my design of five-year old
>ffind is that it is not "eight-bit clean" for international
>character sets.

Which is a problem in SunOS 4.0, which supports 8-bit characters in file
names (such as the symlink "/UNIX(R)" that I had to "/vmunix", where "(R)"
is the ISO Latin #1 "registered trademark symbol" character).

[[ The Unix kernel has always supported 8 bit characters in file names (I
*know* that BSD 4.1 did, and I think that pretty much every version of BSD
and Bell Unix did).  It's just that certain shells stepped on the eighth
bit for their own devious reasons.  But in C you've always been able to do
'creat("A\302C\304");'.  --wnl ]]