Setting the record straight on SunOS 4.0 'fastfind'

[Matt Landau]

In comp.sys.sun (<2359 at kalliope.rice.edu>), Our Moderator, in response
to some questions about find, says:

>Uhhh, I think you both came from the twilight zone.  Neither "find
>filename" nor "find '*filename*'" will have much effect.  The first
>argument(s) to find are the directories in which to start the recursive
>search.  

Actually, if you give find a single non-option argument, it will look in
/usr/lib/find/find.codes for strings that contain that argument as a
substring.  The find.codes file is essentially a pre-cached view of the
filesystem space, arranged for very fast lookup.

The trick is knowing how to build /usr/lib/find/find.codes, since there is
absolutely no documentation on it!  However, if you look in the
/usr/lib/find directory, you'll find a csh script called "updatedb", which
builds find.codes for you.  I arrange to have it run every night from
cron, after which I can go to some server and say "find core" to find
every file that contains the string "core" without waiting for find to
traverse all the filesystems.

Updatedb only works on type 4.2 filesystems, so you have to run it on each
of you servers, and it only builds a cache for 4.2 filesystems, so you
have to do "find string" on each server to find all instances of what
you're looking for.  In spite of that, it's a big win over waiting for
find to walk 3 gigabytes of disk every time you want to hunt something
down.

[[ Yeah, I kind of blew it.  I was unaware of the "fast find" code that
had been incorporated in 4.3.  I've been too busy using Suns that I have
not been able to keep up with the rest of the Unix world.  Sun did indeed
incorporate the fast find code in their distributions of "find", but they
could not come up with an easy way of making the updatedb stuff work
properly in a distributed (NFS) environment.  So, they never documented
that usage of find and never set up "updatedb" in crontab.  That's why I
got confused.  --wnl ]]