Linux has more than one tool for finding files, and picking the right one for the situation saves real time. This guide is a map of the territory before diving into locate and find individually in their own dedicated articles.

The four tools and what each is actually for

locate filename    # fast, searches a prebuilt index, can be slightly stale
find /path -name filename   # slower, searches live, extremely flexible filtering
which commandname    # finds the exact executable that would run for a command
whereis commandname   # finds a command's binary, source, and man page together

Each of these solves a genuinely different problem, even though they can feel interchangeable to a beginner searching for “the file finding command” as a single concept.

locate: fast, index-based, slightly stale

locate nginx.conf
# /etc/nginx/nginx.conf
# /etc/nginx/sites-available/nginx.conf.bak

locate searches a database built ahead of time, usually refreshed once daily by a scheduled job called updatedb. Because it is reading from a prebuilt index rather than scanning the disk live, it returns results almost instantly, even on a filesystem with millions of files. The tradeoff: a file created in the last few hours, or deleted recently, might not be reflected accurately until the index refreshes again.

sudo updatedb
# manually refresh the index right now, if you need current results

find: slower, but searches live and filters deeply

find / -name "nginx.conf" 2>/dev/null
# scans the actual filesystem right now, always accurate,
# but noticeably slower on a large disk

find . -name "*.log" -mtime -7 -size +10M
# find only .log files modified in the last 7 days
# that are also larger than 10 megabytes

find always reflects the current, live state of the filesystem, and its filtering options go far beyond filename matching: modification date, file size, permission mode, owner, file type, and much more, all combinable in a single command. This flexibility is why find remains essential even though locate is faster for a simple name lookup.

which: what would actually run for a command name

which python3
# /usr/bin/python3

which -a python3
# /usr/bin/python3
# /usr/local/bin/python3

which searches only the directories listed in your PATH environment variable, in order, and reports the first matching executable, the one that would actually run if you typed that command name. -a shows every match across your entire PATH, useful for diagnosing situations where multiple versions of the same tool are installed and you are not sure which one is taking priority.

whereis: binary, source, and documentation together

whereis nginx
# nginx: /usr/sbin/nginx /etc/nginx /usr/share/man/man8/nginx.8.gz

whereis searches a fixed set of standard system locations and reports everything it finds related to a given command name at once: the binary itself, any associated source code if installed, and manual page documentation. This gives a broader picture than which, which only cares about the specific executable that would run.

Choosing the right tool in practice

# "Where is this config file?" -> locate first, it's fast
locate httpd.conf

# "Find every file over 500MB in my home directory"
# -> locate cannot do this at all; find is required
find ~ -size +500M

# "Which python am I actually running?"
which python3

# "I need everything related to the nginx command: binary, docs, config"
whereis nginx

A reasonable default habit: reach for locate first when you just need a fast filename lookup and can tolerate a database that might be a few hours stale. Reach for find the moment you need guaranteed-current results or any filtering beyond a plain filename match. Reach for which specifically when the question is about which version of a command will execute. Reach for whereis when you want the fuller picture, binary plus docs plus source, in one shot.

Searching by content, not filename

None of these four tools search inside file contents by default; they all operate on filenames, paths, and metadata. Searching for text within files is grep’s job:

grep -rl "TODO" .
# recursively search every file under the current directory
# for the text "TODO", listing only matching filenames

find . -name "*.py" -exec grep -l "import requests" {} \;
# narrow the search to .py files first with find,
# then search their content with grep

Combining find to narrow down which files to look at with grep to search their actual content is a common and powerful pattern once both tools are understood individually.

Frequently Asked Questions

What is the fastest way to find a file if I only know part of its name?

locate is generally fastest, since it searches a prebuilt index of the entire filesystem rather than scanning disk in real time. Run locate partial_name, and it returns matching paths almost instantly. The tradeoff is that its index only updates periodically (usually once a day via a scheduled job, or manually with updatedb), so a file created moments ago might not show up yet.

When should I use find instead of locate?

Use find when you need to search based on live, current filesystem state rather than a potentially stale index, or when you need to filter by criteria locate cannot handle at all, such as file size, modification date, permissions, or file type. find is slower because it walks the actual filesystem in real time, but its results are always accurate at the moment you run it, and its filtering capability is far more powerful.

What is the difference between which and whereis?

which searches only the directories listed in your PATH environment variable and reports the exact executable that would run if you typed that command name, which is useful for confirming which version of a program is actually being used. whereis searches a fixed set of standard system locations for a program’s binary, its source code, and its manual pages all at once, giving a broader picture than which, which only cares about the runnable executable.

Why does locate sometimes show files that no longer exist?

locate searches a database (typically /var/lib/mlocate/mlocate.db) that is only refreshed periodically, commonly once a day by a scheduled job. If a file was deleted after the last database update, locate still reports it as existing until the next update runs, since it is reading from a cached snapshot rather than checking the live filesystem. Running sudo updatedb manually refreshes the index immediately if you need current results right away.

Can I search for files by content, not just by filename?

Yes, but neither locate nor find search file content directly by default; both operate on filenames and metadata. Searching inside file contents is grep’s job instead, typically combined with find to first narrow down which files to search, such as find . -name “*.log” -exec grep -l “ERROR” {} ;, or more directly using grep -r “ERROR” . to search recursively through every file in a directory tree at once.

Which tool should I reach for by default when I am not sure?

For a quick “where is this file” lookup by name, start with locate for speed. If it comes up empty, is not installed, or you need to filter by size, date, permissions, or type, switch to find, which covers essentially everything locate can do plus a great deal more, at the cost of being somewhat slower on a very large filesystem.