Use find when you know the directory to inspect and need its current entries; use an indexed search when you need to discover a path across a prepared database. Neither a blank result nor a fast response proves that a file is absent. The important differences are search scope, matching rules, permissions and database coverage. This comparison was checked on 15 October 2026 against the GNU find manual and the plocate project's manuals. It includes a small synthetic GNU find check, not a speed ranking or an exhaustive filesystem audit. There are no affiliate links or paid offers.

First identify the implementation. The command named locate may be GNU locate, mlocate, plocate or another implementation, depending on the system. Run locate --version or consult the installed manual; if the command is absent, that does not mean the files are absent. The indexed examples below explicitly use plocate, not a promise that every locate supports identical options. The traversal examples target GNU find on Linux, not an assurance of identical BSD or macOS behavior.

For a read-only search inside your Documents directory, use: find "$HOME/Documents" -type f -name '*.pdf' -print. The double quotes preserve the directory as one argument even if its path contains spaces. The single quotes prevent the shell from expanding the wildcard before find receives it. Here -name matches the final file-name component, -type f selects regular files, and -print displays matching paths. Use an existing starting directory appropriate to your machine; Documents is an example, not a directory guaranteed to exist.

Change -name to -iname when case-insensitive matching is wanted: find "$HOME/Documents" -type f -iname '*.pdf' -print. In our synthetic fixture this included REPORT.PDF as well as report.pdf. GNU find's name pattern also matched .hidden.pdf; a leading dot does not automatically exclude an entry. Neither example searches the text inside a document. If you remember a sentence rather than a filename, you need a content-search workflow and, for formats such as PDF, suitable text extraction.

Narrow the starting tree before widening the search. Searching from / can traverse unrelated system directories and produce permission errors or substantial I/O. Do not automatically hide errors with 2>/dev/null: an inaccessible subtree is relevant evidence when explaining a missing result. A clean result still reflects a changing filesystem, not an atomic snapshot. If the search is incomplete, record the directory and error rather than treating the visible matches as a complete inventory.

GNU find does not follow symbolic links by default (-P). A linked directory inside the chosen tree therefore does not automatically expose its target's files, and -type f does not include the symlink itself under this default. Our fixture included a directory symlink to an outside folder; the outside PDF was not returned. The -L option changes traversal and type behavior and belongs before the starting path. Do not add it merely to silence a discrepancy: first decide whether following linked trees is intended. The -xdev option can avoid descending onto other devices, but that also intentionally reduces coverage.

To skip one known archive subtree, use: find "$HOME/Documents" -path "$HOME/Documents/archive" -prune -o -type f -name '*.pdf' -print. The left branch prunes that exact path; the right branch prints matching regular files elsewhere. This command was checked on a synthetic tree in the equivalent form with -print0 for unambiguous verification. It omits archive/old.pdf while retaining the matching files outside that directory. Keep this as a search command: pruning and deletion have different interactions, and no deletion action is needed to locate a file.

For indexed discovery with plocate, start with: plocate -b -i report. Here -b restricts the match to the basename instead of matching directory components, and -i requests case-insensitive matching. Plain patterns are substring searches. To express a wildcard substring explicitly, use: plocate -b -i '*report*.pdf'. Keep the pattern quoted so the shell does not expand it. With plocate, multiple patterns must all match; do not assume that plocate report invoice means report OR invoice. Its manual identifies this as a difference from mlocate's default behavior.

A useful follow-up is: plocate -e -b -i report. The -e option filters indexed candidates to entries that exist when the search runs. It does not scan for newly created files absent from the database and does not refresh the index. The plocate manual also says this existence check does not follow symlinks by default and provides no option to change that behavior. Treat an existing path, an accessible target and the intended document as separate checks before opening or acting on a result.

Database freshness is only one explanation for missing names. Read the applicable updatedb configuration and the local update service or schedule before deciding an update will help. The plocate project's updatedb.conf manual documents PRUNEFS for filesystem types, PRUNENAMES for directory names, PRUNEPATHS for directory paths and PRUNE_BIND_MOUNTS for bind-mount handling. Actual distribution configuration can differ from documented defaults. A fresh index still omits deliberately excluded contents; repeatedly rebuilding it does not change those exclusion rules.

There is a subtle diagnostic clue: the configuration manual says a pruned directory's own path can be indexed while its contents are not. Seeing the directory in a locate result therefore does not prove its files were scanned. Check whether the containing mount existed during indexing and whether the path falls under an exclusion. Do not assume a universal daily update schedule or disable exclusions indiscriminately; confirm the machine's intended indexing policy with its administrator when necessary.

Visibility is another limit. plocate describes filtering results according to the calling user's read and execute permissions on parent directories. A database containing a name does not guarantee that every user can see it, and visibility in a result does not establish permission to read the file contents. Start with the ordinary account used for the task. Changing identity or permissions solely to get more results can change the question you are answering. Its exit status 1 can mean no matches or an error, so keep diagnostic output when troubleshooting scripts.

For machine processing, choose a delimiter that can represent unusual filenames: GNU find -print0 and plocate -0 emit NUL-separated paths. A filename can contain a newline, so one printed line is not always one file. Use a consumer that explicitly accepts NUL-separated input; do not feed these results through whitespace splitting or a shell for-loop over command substitution. This protects path boundaries, not against every race between finding a path and later using it. The examples here perform no edits or deletion.

We checked three GNU find cases with version 4.9.0 in an isolated temporary fixture: case-sensitive PDF matching, case-insensitive PDF matching and excluding a named archive directory. The fixture included a hidden PDF, uppercase extension, a space in a filename, an embedded newline, a nested PDF and a directory symlink. The returned path sets matched the expected sets with NUL-separated output, and the linked outside PDF was excluded under default traversal. These are small functional checks, not performance results. plocate examples and configuration behavior are documentation-reviewed, not locally executed; no permission-denied, BSD or macOS test is claimed.

Use this missing-file checklist in order. Confirm that you are searching names rather than contents. Check spelling, case, wildcard quoting and basename versus whole-path matching. Confirm the starting directory, current mount and symlink behavior for find. For an indexed search, inspect the selected database, update timing, exclusions and caller visibility; then search the expected directory directly with find if it is accessible. Review errors and verify any returned path before use. A negative indexed search alone cannot establish that a file never existed or has been deleted.

The practical verdict is a two-tool workflow, not a universal winner: use plocate for indexed name discovery, then find for a scoped traversal when freshness or filtering matters. Prefer the narrower command that answers your question and keep its limits visible. If you are locating files to compare their contents, continue with the linked diff-versus-cmp guide after confirming the paths. If files appear in a directory search but not in a Git workflow, the linked ignore/index guide explains a different layer of visibility; Git tracking is not the same as filesystem existence.