File search: the setup order that holds up

A search that returns four thousand results and a search that returns nothing are the same failure wearing different clothes. Both mean the query was answered by a system whose scope nobody set on purpose. Searching for file search tsukaikata usually starts after the second or third time this happens in a week. The fix is not a faster keystroke. It is five decisions made once, in an order where each one makes the next one obvious.

Two different searches share one box

macOS answers file queries through two mechanisms that behave nothing alike, and the same text field sends a query to either of them depending on context.

The first mechanism reads an index. A background process catalogues filenames, metadata and, for many file types, the text inside. Spotlight and the search field in a Finder window both query that catalogue, which is why results start appearing before the last character is typed. The second mechanism scans. Tools like grep and ripgrep open files one at a time and read them, ignoring whatever the catalogue says. That takes seconds to tens of seconds over tens of thousands of files.

The important difference is not speed. It is what each one is capable of returning. An index cannot return something it never catalogued. A scan cannot return something outside the directory it was pointed at, but within that directory it misses nothing.

There is a third split hiding inside the index route: matching on filename versus matching on contents. Finder offers both as suggestions the moment a word is typed, and picking one without noticing is the single most common reason two people running the same query get different lists. Apple's own documentation treats a surprising result as a normal starting point rather than a malfunction:

If your search turns up unexpected or too many results, you can refine it. Source: support.apple.com

Refining is downstream. The decision that comes first is which mechanism a search begins with, and that depends on what is usually remembered about the missing file. Filenames for some kinds of work, a phrase from inside the document for others. Choosing neither means running both every time.

Decision one: where a search starts

Finder has a setting for search scope, and most people have never opened it. Finder menu, Settings, then the Advanced tab. The row reads When performing a search: and offers three options:

Option	What it does	Suits
Search This Mac	Ignores the current folder and queries everything	Files whose location is genuinely unknown
Search the Current Folder	Limits results to the window that was open	Work organised into per project folders
Use the Previous Search Scope	Repeats whatever scope was used last	Repeated passes over the same area, same day

The default is Search This Mac. That is why opening a project folder, typing a word, and getting hits from a download three years old feels like the machine ignoring an instruction. No instruction was given. The window being open is not a scope.

Pick based on how the work is shaped rather than on which sounds tidier. Someone whose files live in per client folders gets far less noise from Search the Current Folder, then widens manually on the rare miss. Someone who saves everything to Desktop and Downloads is better served by Search This Mac, because narrowing by scope was never going to help. Use the Previous Search Scope is the one to avoid unless the same area is being searched repeatedly in a single sitting, since a result set that depends on what happened an hour ago cannot be explained later.

Whatever gets chosen, add one habit to it: the scope buttons sit directly under the search field, showing This Mac next to the folder name. Reading that row before reading the results turns most confusing searches into a one second diagnosis.

Decision two: what the index does not cover

An index is fast because it is prepared in advance, which means anything not prepared is invisible to it. Knowing the edges in advance prevents hours lost to a file that was never missing.

The usual gaps:

• Folders and disks added to the exclusion list in Spotlight settings, often years ago for a client with confidentiality terms, and never removed
• Disk images and encrypted volumes that are not currently mounted
• External drives that are disconnected, and network shares that dropped
• Any folder whose name ends in .noindex
• Files still inside an archive that was never expanded

External drives deserve a second note. A large volume that has just been plugged in is often still being catalogued, so results come back partial for several minutes. Anyone who keeps source material on an external disk should treat that wait as part of the procedure rather than as evidence that something was deleted.

Cloud sync folders behave differently again. With storage optimisation turned on, the entry stays on the Mac while the contents live on a server. A file that matches by name but never by an interior phrase is the signature of that state. Opening the file once, then repeating the same query, separates a sync question from an index question in about ten seconds.

Decision three: one query syntax, chosen on purpose

Three ways of expressing the same query exist, and deciding between them mid search is itself a cost. Pick a default, then fix the order of fallbacks.

Attribute prefixes in the Finder search field come first for document work. Typing kind:pdf before the search term removes images, mail and messages from the result list without touching the criteria rows. date:today and kind:folder work the same way, and they compose.

Querying the index from a shell comes second. mdfind reads the same catalogue Spotlight uses and returns paths, one per line. Adding -onlyin ~/Documents cuts a three thousand line answer down to something readable. Because the output is already a list of paths, it feeds straight into the next command instead of needing to be retyped.

Scanning comes third. rg and grep read file contents directly and do not care what the catalogue knows. For code, logs, and anything inside an excluded folder, this is the only route that can answer at all.

The choice of default follows the material. Documents point at the first route, source code at the third. The other two are not spares, they are a defined escalation path: when the default returns nothing, the next thing to try is already decided, and no thinking happens at the moment of frustration.

Decision four: repeated searches become saved conditions

A query typed twice a week is not a search technique, it is a missing setting. File menu, New Smart Folder, then add criteria rows with the plus button at the right. Type, modification date and location stack together, and saving the result puts it in the sidebar, where it re evaluates every time it opens.

The durable ones are built from attributes that outlive naming habits. A condition reading "inside Documents, kind is PDF, modified within the last 7 days" keeps working after the invoice template changes. A condition reading "name contains invoice" goes quietly empty the month a client switches formats, and nothing announces the failure. Build with type, period and location. Reach for the filename only when nothing else distinguishes the set.

Location deserves a rule of its own. A smart folder scoped to This Mac will happily surface cached copies, mail attachments and files inside application support folders, all of which match the criteria and none of which are the document being looked for. Scoping the same condition to Documents, or to a single project folder, removes that class of noise permanently rather than one result at a time. The narrower scope also makes the condition cheap to evaluate, so the sidebar entry opens without a visible pause even on a volume holding a decade of work.

Three saved conditions cover most of what gets typed by hand: documents touched this week, one specific file type, and anything above a size threshold. A saved condition is a net that catches the common case, not a guarantee, so keep the wide manual search as the documented fallback when the sidebar comes up short.

Decision five: how a result gets handed off

Most guidance treats the moment the file appears as the end. It is not. Something always happens next: it gets opened, attached, copied elsewhere, or passed to a command. An undecided handoff puts the time back that a faster search just saved.

In Spotlight results, selecting an item and holding the Command key shows its location under the preview, which prevents opening the wrong one of two identically named files.

In a Finder window, select the file, open the Edit menu, then hold Option. Copy changes to Copy as Pathname, putting the full path on the clipboard. For anyone who finishes a search by running a command, that is the handoff worth standardising on. Dragging a file into a terminal window achieves the same thing with quoting already handled.

One method used every time beats five methods chosen situationally, because the decision itself is what costs the seconds.

The five decisions are also the diagnostic order

When results look wrong, walk the same list from the top. Is this query matching names or contents. Where did the scope start. Is the target location inside the index at all. Does the syntax match the route. Is the delay actually after the result rather than before it.

That pass takes about a minute and usually ends at the second or third question. Rebuilding the Spotlight index does fix real problems, but starting there costs a long wait and, if it works, explains nothing about why the failure happened. It belongs after the four cheap checks, not before them.

Checking the index before rebuilding it

There is a cheaper step between the four questions and a full rebuild: asking whether indexing is switched on for the volume at all. mdutil -s / reports the status for the startup disk, and running it against an external volume path reports that volume separately. A disk that answers with indexing disabled explains every symptom at once, and turning it back on is a smaller operation than discarding a working catalogue.

A rebuild, requested with mdutil -E, throws the existing catalogue away and starts over. On a disk holding hundreds of thousands of files that runs for a long stretch, during which searches return partial results that look like new failures. Start it when the machine is not needed, not in the middle of looking for something, and note that partial results during the rebuild are expected rather than a second fault.

Worth separating from all of this: a search that is slow rather than wrong. Slowness usually points at scanning where an index would do, or at a query that crosses a network share. Wrongness points at scope and coverage. Treating the two as one problem is how an afternoon disappears.

What to change first

Open Finder Settings, Advanced, and set the search scope deliberately today, then spend ten minutes reading the Spotlight exclusion list. Those two take a quarter hour and remove most of the days where a file appears to have vanished. If the count that stays stubbornly high is the number of trips between a folder window, a terminal and an assistant, the search settings were never the constraint, and the comparison of file managers is the more useful page to read next, with Atriens built around removing exactly those trips.