Right, so you’ve just learned about find, and you’re thinking, “This is powerful, but it feels like searching an entire city block for your car keys by walking every inch of it.” You’re not wrong. That’s where locate comes in. It’s the speed demon of the file-searching world. Instead of crawling through your filesystem in real-time, it consults a pre-built database. The result? It returns answers almost instantly.

The trade-off, and there’s always a trade-off, is that its database isn’t live. It’s a snapshot, typically updated once a day by a cron job. This means if you created a file five minutes ago, locate probably won’t know it exists yet. It’s like having a brilliant friend with a photographic memory, but they only take one picture per day. For finding ancient config files you forgot about or that source code from last month, it’s unbeatable.

How the Magic (and the Mess) Happens: updatedb

The locate command is useless without its database, which is built and updated by the updatedb command. Now, updatedb is typically run automatically every 24 hours by a root-owned cron job in /etc/cron.daily/ or similar. You can see its logic by peeking at its config file, usually /etc/updatedb.conf or /etc/updatedb.conf. Let’s break down the important bits you’ll find in there:

# Let's see what rules our updatedb is using
cat /etc/updatedb.conf

You’ll likely see something like this:

PRUNE_BIND_MOUNTS="yes"
PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media /home/.cache"
PRUNEFS="NFS nfs nfs4 proc smbfs autofs"

This file is where the system administrator tells updatedb, “Hey, for the love of sanity, don’t waste time and database space indexing these things.” PRUNEPATHS is the big one—it excludes entire directories. PRUNEFS avoids networked and virtual filesystems, which is generally smart unless you want your database update to hang trying to index a dead NFS server.

The most common pitfall with locate stems directly from this configuration. If your file is in a pruned path (like /tmp), it will never appear in the database. This isn’t a bug; it’s a very deliberate feature to keep the database small and relevant.

Using locate: It’s Not Complicated (Until It Is)

The basic usage is brain-dead simple. You’re just pattern matching against the database.

# Find anything with 'passwd' in its path
locate passwd

# Want to find only files called 'passwd', not just containing the string?
# Use the -b (basename) flag and a pattern with a wildcard to anchor it.
locate -b '\passwd'

# Need case-insensitive search? Of course you do.
locate -i readme.md

Here’s the first “questionable choice” you’ll run into: the pattern you give locate isn’t a standard regex or even a standard glob. It’s a weird hybrid. By default, it treats your pattern as *pattern*. This is why locate passwd finds /etc/passwd, /etc/passwd-, and /usr/share/doc/passwd/README. This is usually what you want, but it can be surprising.

If you want real, honest-to-goodness regex matching, use the --regex (-r) flag.

# Find all .jpg and .png files using a regex
locate --regex '\.(jpg|png)$'

When locate Betrays You (And How to Fix It)

The number one complaint is “locate can’t find my new file!” You now know the first reason: the database is old. The fix is easy—update the database manually. This requires sudo because the database is owned by root.

# Manually rebuild the database. Go get a coffee if it's a large filesystem.
sudo updatedb

# Now try your search again
locate my_new_file.txt

The second reason is pruning, as we discussed. If your file is in /tmp, you’re out of luck. The third reason is more subtle: permissions. The updatedb run is executed by root, so it can see every file on the system. However, when you run locate, you’re just a user. The locate database stores paths but not permissions. So, locate will happily tell you about a file in /root/secret_plans.txt, but you won’t be able to cat it. It’s like a GPS that directs you straight into a military base. Useful, but also a quick way to get into trouble.

Best Practices and The Gotcha

  1. Know Its Limits: Remember the snapshot-in-time nature. Use find for real-time, precise searches on a small scale. Use locate for blazing-fast, “I know it’s around here somewhere” searches.
  2. Update Manually When Needed: If you’ve just installed a bunch of software or unpacked an archive and need to find files from it, just sudo updatedb. It’s a blunt instrument, but it works.
  3. Mind the Privacy/Security Leak: Be aware that locate can reveal the existence of files users shouldn’t know about. This is why on multi-user systems, the locate database is often configured to be only readable by root (/var/lib/mlocate/mlocate.db) and a secure locate command (slocate or plocate) is used to filter results based on user permissions. Modern systems (often using plocate) handle this better, but it’s a historic wart worth knowing.

So, in summary: locate is your go-to for raw speed. Just know that its memory is from yesterday, it’s been told to ignore the messy rooms, and it has no concept of security clearance. It’s a brilliant tool, brilliantly flawed, like everything else worth using.