Finding Files and Binaries on Linux: locate, updatedb, which, and type

The locate command finds files by name almost instantly because it does not search the disk at all — it queries a prebuilt index database that the updatedb program refreshes on a schedule, typically once a day. That design makes locate extremely fast but potentially stale: a file created five minutes ago will not appear in results until updatedb runs again (or you run sudo updatedb manually). For live, always-accurate searches you use find; for answering “which binary will actually execute when I type this command,” you use type, which, command -v, and whereis.

How locate and updatedb work

locate (provided today by the plocate package on most distributions, historically by mlocate) reads a compressed index of every pathname on the system — /var/lib/plocate/plocate.db for plocate, /var/lib/mlocate/mlocate.db for mlocate. A query like locate sshd_config is a string match against that index, which is why results return in milliseconds even on a filesystem with millions of files.

The index is built by updatedb, which walks the filesystem and records every path it is allowed to see. Distributions schedule it automatically — classically via a daily cron job in /etc/cron.daily/, on systemd-era systems via a timer unit such as plocate-updatedb.timer (the same daily-maintenance pattern covered in systemd timers vs cron). The configuration file /etc/updatedb.conf controls what gets indexed: PRUNEPATHS lists directories to skip (things like /tmp and /media), and PRUNEFS lists filesystem types to ignore (network mounts, pseudo-filesystems). So a file can be “missing” from locate for two distinct reasons — it is newer than the last index run, or it lives somewhere updatedb is configured to prune.

That first reason is the classic troubleshooting scenario: a file demonstrably exists on disk, ls shows it, but locate returns nothing. Nothing is broken — the database simply predates the file. sudo updatedb rebuilds the index immediately and the file appears in the next query. (Root is needed because the database covers the whole filesystem; mlocate/plocate filter query results per-user so you only see paths you could actually traverse.)

Useful day-to-day flags: locate -i for case-insensitive matching, locate -c to count matches instead of listing them, locate -e to verify each result still exists before printing it (a cheap guard against the opposite staleness problem — files deleted since the last index run), and locate -r for a regular-expression pattern.

locate vs find

	locate	find
Data source	Prebuilt database (updatedb)	Live filesystem walk
Speed	Near-instant	Proportional to tree size
Freshness	As of last updatedb run	Always current
Matches on	Pathname substrings	Name, size, mtime, owner, permissions, type, and more
Can act on results	No (list only)	Yes — -exec, -delete, -ok
Typical use	”Where did that file end up?”	Audits, cleanups, scripted batch operations

The rule of thumb: reach for locate when you know part of a filename and want an answer now; reach for find when you need current truth or want to filter on anything other than the name — find /var/log -name '*.log' -mtime +30, for instance, has no locate equivalent. find’s output also feeds pipelines: piping find into cpio is the classic way to archive exactly the files a search selects.

Which binary will actually run: type, which, command -v, whereis

A different question entirely: two versions of a program exist on the system — say /usr/bin/python3 and /usr/local/bin/python3 — and you need to know exactly which one executes when you type python3, and whether the name is even a real file rather than an alias, shell function, or builtin. The shell resolves a command name in a fixed order — aliases, then functions, then builtins, then the first matching executable in $PATH (left to right, with previously resolved locations cached in a hash table). Four tools let you interrogate that resolution:

• type python3 — a bash builtin, so it sees the shell’s own state. It reports whether the name is an alias, a function, a builtin, or a file, and for files prints the path that will run. type -a python3 lists every resolution in precedence order — the definitive answer when duplicates exist.
• which python3 — an external program that searches $PATH and prints the first executable match. Fast and familiar, but because it is not a builtin it knows nothing about your aliases, functions, or builtins — it can confidently print a path that your shell would never actually execute because an alias shadows it.
• command -v python3 — a POSIX (Portable Operating System Interface)-standard builtin that prints how the name resolves (alias text, function name, or file path). Being standardized, it is the portable choice inside scripts where which behavior varies between systems.
• whereis python3 — searches standard binary, source, and man-page directories and prints everything it finds (whereis -b restricts output to binaries). It does not tell you which copy wins, but it is a quick census of every installed copy plus documentation.

The practical workflow when two copies conflict: type -a python3 to see the full precedence list, then compare with which python3 — if they disagree, an alias or function is intercepting the name, and unalias python3 or a full path invocation gets you the real binary. hash -r clears the shell’s cached lookup table if you have just installed a new copy earlier in $PATH and the shell keeps running the old one.

How the XK0-006 exam tests this

• The stale-database scenario: a recently created file exists on disk but locate finds nothing. The credited explanation is that the locate database has not been refreshed since the file was created — not filesystem corruption, not permissions — and the fix is running updatedb.
• A select-all-that-apply pattern listing tools that identify which executable will run and whether a name is an alias or builtin: which, type, command -v, and whereis are the family to recognize, with type being the one that sees aliases and builtins.
• A tool-choice pattern: given a requirement (search by modification time, or act on results), pick find over locate; given “fastest way to find a path by name,” pick locate.
• An ordering question about shell command resolution — alias before function before builtin before $PATH — often framed as “why does typing the command run something different from what which prints?”

File-search tooling belongs to the System Management domain — the full XK0-006 study guide shows the complete domain breakdown, and Linux+ practice questions will tell you quickly whether locate-versus-which is truly settled.

Quick reference

• locate queries a database; it never touches the live filesystem during a search.
• updatedb rebuilds that database — scheduled daily (cron job or systemd timer), or on demand with sudo updatedb.
• Files newer than the last updatedb run are invisible to locate; that is the expected behavior, not a fault.
• /etc/updatedb.conf (PRUNEPATHS, PRUNEFS) excludes paths and filesystem types from indexing.
• locate -e hides results that no longer exist; -i ignores case; -c counts.
• find searches live and can filter on size, time, owner, and permissions — and act on matches with -exec.
• type -a name shows every way a command resolves, including aliases and builtins; which only searches $PATH.
• command -v is the POSIX-portable resolver for scripts; whereis lists binaries, source, and man pages.