locate command in linux made easy

×

Searching for files is one of the most common tasks in Linux, whether you're looking for a configuration file, troubleshooting an application, or tracking down a forgotten document. Many users start with the find command, which is powerful but can be slow when searching large filesystems.

This is where the locate command becomes useful. Instead of scanning the entire filesystem each time, it searches a prebuilt database and can return results almost instantly. For everyday file searches, this often makes locate one of the fastest and most convenient tools available on Linux.

This guide is designed for beginners and Linux administrators who want a quicker way to find files by name. By the end, you will understand how the locate command works, how its database is maintained, when results may become outdated, and how to use it effectively on Ubuntu, Rocky Linux, and RHEL systems.

Examples

locate is a command that finds files by searching a database instead of scanning your whole disk. Think of it like searching a library's card catalog instead of walking down every aisle checking each shelf yourself.

That database gets built by a separate tool called updatedb, which usually runs automatically once a day through a systemd timer or cron job. Because locate just reads from that pre-built index, it returns results almost instantly even on systems with millions of files, the same way you might quickly check what's in a folder with a simple ls command instead of opening every file one by one. The tradeoff is that it only knows about files that existed the last time the database was updated. If you created a file five minutes ago and the database has not refreshed yet, locate has no idea it exists.

This is the exact reason a lot of beginners get confused the first time they use it. You make a new file, run locate, and get nothing back, even though the file is sitting right there in your home directory.

The PATTERN part is the text you are searching for. It does not need to be the exact filename. locate matches it against the full path, so searching for nginx will return every file and folder anywhere on the system that has "nginx" somewhere in its path, not just files literally named nginx.

The OPTION flags change how the search behaves, whether that means ignoring case, counting results instead of listing them, or only showing files that still actually exist on disk. The daily refresh itself usually runs through a scheduled job, similar to how a lot of routine maintenance gets handled with a cron command entry on older systems.

The simplest way to use locate is to just type the pattern you're looking for. This works fine for a quick first attempt before you reach for any flags.

You can use the asterisk to widen or narrow your search. This is handy when you only remember part of a filename.

Since locate is case sensitive by default, add -i whenever you are not sure how something was named.

Sometimes you don't need the full list, you just want a number. Maybe you're checking how many log files of a certain type have piled up.

A search for something common like .py can return thousands of hits. Use -n to cap the output so you're not scrolling forever.

By default locate checks the entire path, so a search for nginx will also match folders that have nginx anywhere in their directory name. Use -b when you want the exact filename instead.

For more specific matches, like files that end in either .mp4 or .avi, a regular expression saves you from running two separate searches.

If results feel off, checking the database stats tells you how large it is and gives you a clue about how stale it might be. It's a similar habit to checking disk space with df command before you start cleaning up files, a quick sanity check before you trust what you're looking at.

This is close to the situation that taught me to actually use locate properly. You inherit a server and someone mentions there's a custom php.ini override somewhere, but nobody remembers exactly where.

Before a script deletes anything, it's smart to preview exactly what it will touch. This pairs well with checking actual folder sizes using du command so you know roughly how much space a cleanup will free up. Piping locate into a count first gives you a sanity check.

The -e flag here matters a lot. Without it, that count could include files that were already deleted weeks ago, which would throw off your cleanup estimate entirely.

This is the trap nearly everyone falls into at least once. You create a brand new file and immediately try to locate it.

The fix is to refresh the database manually before searching again.

On a server with a few hundred thousand files, running find without narrowing it down first can take a genuinely long time, especially over a slow disk or a busy production box. locate skips that entire problem because it's reading an index, not walking the tree. Once you get used to that speed, going back to a blind find search for something simple feels painful.

The part that actually matters for production work is knowing locate's limits cold. If you ever automate something around file existence checks, relying on locate without -e or without a fresh updatedb run can quietly feed wrong information into a script. According to the official locate man page, the command only ever reflects what was in the database at the time it was built, nothing more current than that.