locate

What it does

locate finds files and directories by name almost instantly by searching a prebuilt index (maintained by mlocate or the newer plocate) instead of walking the live filesystem the way find does. The tradeoff for that speed is freshness: the index is only as current as the last time updatedb ran (typically once a day via a cron job or systemd timer), so very recently created or deleted files may not show up — or may show up as still existing — until the database is refreshed.

Beginner examples

• locate nginx.conf — find any path containing "nginx.conf" anywhere on the indexed filesystem
• locate -i readme — case-insensitive search for "readme"
• locate '*.pdf' — find all indexed paths ending in .pdf (quote the pattern so the shell doesn't expand it first)
• locate -c error — print just the number of matches instead of listing them

locate httpd.conf

Advanced examples

• Limit the number of results returned: locate -n 20 backup
• Only show results for files that still actually exist on disk right now: locate -e old-report.csv
• Require multiple patterns to all match the same path: locate -A nginx conf
• Use a full regular expression instead of the default glob-like matching: locate -r '\.log$'
• Force a fresh database before searching for a file created moments ago: sudo updatedb && locate newly-created-file.txt

locate -i -n 15 '*.service'

Common mistakes

• Searching for a file that was just created and assuming locate is broken when it returns nothing — the database simply hasn't been refreshed yet; run sudo updatedb or use find for a live search.
• Forgetting to quote glob patterns like *.log, letting the shell expand them against the current directory before locate ever sees the pattern.
• Assuming locate sees every file on the system regardless of permissions — mlocate filters results based on what the calling user is allowed to read, and some paths may be excluded from indexing entirely (e.g. via PRUNEPATHS in updatedb.conf).
• Relying on locate for security-sensitive existence checks — since the database can be stale, a missing or present result isn't a guarantee about the current state of the filesystem.

Tips

• Run sudo updatedb manually right before a locate search if you know the file you need was created very recently.
• Use locate -i liberally — filename casing is often inconsistent, and case- insensitive search avoids missing an otherwise-correct match.
• For directories intentionally excluded from indexing (like /tmp or removable media in many default configs), you'll need find instead, since locate will never see files there.

Best practices

• Reach for locate first when you need a fast name-based search of a whole system and can tolerate the index being up to a day stale; fall back to find when you need guaranteed real-time accuracy or content/attribute-based filtering (size, mtime, permissions).
• If locate seems to be missing recent files regularly, check that the updatedb timer/cron job is actually enabled and running on schedule.
• Don't rely on locate alone for security auditing of file existence; combine it with find or direct checks when correctness matters more than speed.

Real-world use cases

• Quickly finding the full path of a configuration file you know the name of but not the location, e.g. locate httpd.conf.
• Auditing a system for leftover files matching a pattern (like old log or backup files) across the entire filesystem in a fraction of the time find / would take.
• Locating all instances of a particular library or binary across a large filesystem during troubleshooting.

Common interview questions

• Why might locate fail to find a file that clearly exists? Because locate searches a prebuilt database that's only updated periodically (via updatedb), so a very recently created file won't appear until the next database refresh.
• How does locate achieve its speed advantage over find? It performs a lookup against a precomputed, indexed database of paths, avoiding the filesystem traversal that find performs live at query time.
• How do you force the locate database to reflect the current filesystem state? Run sudo updatedb to rebuild the index immediately instead of waiting for its scheduled run.