locate(1) has only one big advantage over
find(1), though, has many advantages over
find(1) is primordial, going back to the very first version of AT&T Unix. You will even find it in cut-down embedded Linuxes via Busybox. It is all but universal.
locate(1) is much younger and nonstandard.
The earliest ancestor of
locate(1) appeared in 1983, but it wasn't widely shipped as "
locate" until 1990. BSD didn't adopt it until 1994, in 4.4BSD.
There are three main flavors of
locate(1) in the wild today. In increasing order of features, they are BSD
mlocate, and GNU
locate. The BSDs and Mac OS X ship BSD
locate. Most Linuxes ship GNU
locate, but Red Hat Linuxes and Arch ship
Recent versions of GNU
mlocate implement all BSD
mlocate implements 6 additional options not in BSD
locate implements those six plus another four:
-p. (I'm ignoring aliases and minor differences like
The big iron Unixes don't ship any implementation of
locate. (See the
man page indexes for Solaris, AIX and HP-UX.)
Bottom line, you can't count on
locate to be available on all machines, and where present, you can't count on consistent behavior between implementations.
find(1) has a powerful expression syntax, with many functions, Boolean operators, etc.
find(1) can select files by more than just name. It can select by:
- file type
- depth within the subtree...
When finding files by name, you can search using file globbing syntax in all versions of
find(1), or in GNU or BSD versions, using regular expressions.
Current versions of
locate(1) accept glob patterns as
find does, but BSD
locate doesn't do regexes at all. If you're like me and have to use a variety of machine types, you find yourself preferring
grep filtering to developing a dependence on
locate needs strong filtering more than
find does because...
find(1) doesn't necessarily search the entire filesystem. You typically point it at a subdirectory, a parent containing all the files you want it to operate on.
locate(1) simply spews up everything[*] it knows, leaving it to
grep filtering and such to cut its eruption down to size.
find(1) can do things to files it finds, in addition to just finding them. The most powerful and widely supported such operator is
-exec, but there are others. In recent GNU and BSD find implementations, for example, you have the
find(1) runs in real time, so its output is always up to date.
locate(1) relies on a database updated hours or days in the past, its output can be outdated. (This is the stale cache problem.) This coin has two sides:
locate can name files that no longer exist.
mlocate have the
-e flag to make it check for file existence before printing out the name of each file it discovered in the past, but this eats away some of the
locate speed advantage, and isn't available in BSD
locate will fail to name files that were created since the last database update.
You learn to be somewhat distrustful of
locate output, knowing it may be wrong.
find(1) never has any more privilege than the user running it.
locate provides a global service to all users on a system, it wants to have its
updatedb process run as
root so it can see the entire filesystem. This leads to a choice of security problems:
updatedb as root, but make its output file world-readable so
locate can run without special privileges. This effectively exposes the names of all files in the system to all users. This may be enough of a security breach to cause a real problem.
locate is configured this way on Mac OS X and FreeBSD.
Write the database as readable only by
root, and make
setuid root so it can read the database. This means
locate effectively has to reimplement the OS's permission system so it doesn't show you files you can't normally see. It also increases the attack surface of your system, specifically risking a root escalation attack.
Create a special "
locate" user or group to own the database file, and mark the
locate binary as
setuid/setgid for that user/group so it can read the database. This doesn't prevent privilege escalation attacks by itself, but it greatly mitigates the damage one could cause.
mlocate is configured this way on Red Hat Enterprise Linux.
You still have a problem, though, because if you can use a debugger on
locate or cause it to dump core you can get at privileged parts of the database.
I don't see a way to create a truly "secure"
locate command, short of running it separately for each user on the system, which negates much of its advantage over
Bottom line, both are very useful.
locate(1) is better when you're just trying to find a particular file by name, which you know exists, but you just don't remember where it is exactly.
find(1) is better when you have a focused area to examine, or when you need any of its many advantages.
[*] Obviously if you have a variant of
slocate(1), an unprivileged user might not get literally everything out of it that it knows in its database.