What are the pros and cons of each? When one have benefits over the other?
locate(1) has only one big advantage over
find(1), though, has many advantages over
locate(1)is much younger than
find(1). The earliest ancestor of
locate(1)didn't appear until 1983, and it wasn't widely available as "
locate" until 1994, when it was adopted into GNU findutils and into 4.4BSD.
locate(1)is also nonstandard, thus it is not installed by default everywhere. Some POSIX type OSes don't even offer it as an option, and where it is available, the implementation may be lacking features you want because there is no independent standard specifying the minimum feature set that must be available.
There is a de facto standard, being BSD
locate(1), but that is only because the other two main flavors of
locateimplement all of its options:
mlocateimplements 6 additional options not in BSD
locateimplements those six plus another four:
-p. (I'm ignoring aliases and minor differences like
The BSDs and Mac OS X ship BSD
Most Linuxes ship GNU
locate, but Red Hat Linuxes and Arch ship
mlocateinstead. Debian doesn't install either in its base install, but offers both versions in its default package repositories; if both are installed at once, "
Oracle has been shipping
mlocatein Solaris since 11.2, released in December 2014. Prior to that,
locatewas not installed by default on Solaris. (Presumably, this was done to reduce Solaris' command incompatibility with Oracle Linux, which is based on Red Hat Enterprise Linux, which also uses
Older "real" Unixes generally did not include an implementation of
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...
Current versions of
locate(1)accept glob patterns as
finddoes, but BSD
locatedoesn't do regexes at all. If you're like me and have to use a variety of machine types, you find yourself preferring
grepfiltering to developing a dependence on
locateneeds strong filtering more than
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. The typical behavior for a
locate(1)implementation is to spew up all files matching your pattern, leaving it to
grepfiltering and such to cut its eruption down to size.
locate /will probably get you a list of all files on the system!)
There are variants of
slocate(1)which restrict output based on user permissions, but this is not the default version of
locatein any major operating system.
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:
locatecan name files that no longer exist.
-eflag 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
locatespeed advantage, and isn't available in BSD
locatewill fail to name files that were created since the last database update.
You learn to be somewhat distrustful of
locateoutput, knowing it may be wrong.
find(1)never has any more privilege than the user running it.
locateprovides a global service to all users on a system, it wants to have its
updatedbprocess run as
rootso it can see the entire filesystem. This leads to a choice of security problems:
updatedbas root, but make its output file world-readable so
locatecan 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.
locateis configured this way on Mac OS X and FreeBSD.
Write the database as readable only by
root, and make
setuidroot so it can read the database. This means
locateeffectively 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
setuid/setgidfor 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.
mlocateis configured this way on Red Hat Enterprise Linux.
You still have a problem, though, because if you can use a debugger on
locateor 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"
locatecommand, 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.
locate uses a prebuilt database, which should be regularly updated, while
find iterates over a filesystem to locate files.
locate is much faster than
find, but can be inaccurate if the database -can be seen as a cache- is not updated (see
find can offer more granularity, as you can filter files by every attribute of it, while
locate uses a pattern matched against file names.
find is not possible for a novice or occasional user of Unix to successfully use without careful perusal of the man page. Historically, some versions of
find didn't even default the
locate is less flexible, but far more intuitive to use in the common case.
A slight drawback of locate is that it may not be indexing the area of the file system you are interested in. On Debian desktop systems, for example Linux Mint 17.2, the /etc/updatedb.conf file is configured to exclude certain areas from consideration, including /tmp, /var/spool, and /home/.ecryptfs.
Ignoring /home/.ecryptfs prevents file names in encrypted directories from being exposed to unauthorised users. However, if your home directory is encrypted with ecryptfs, it also means your home directory is not indexed, and locate will therefore never find anything in your home directory. This might make it largely useless for you (it does for me). In addition to not finding results, the updatedb process will periodically load your disk for no benefit, and might as well be disabled if you are the main or only user of the system.