Learn › Linux Foundations › Search
locate - a hands-on Linux lab on a real virtual machine.
Why locate is fast and what it costs: locate reads a saved snapshot of paths built by updatedb, while find scans the live disk. Build the private snapshot, read it with -d, watch a brand-new file go missing because the snapshot is stale, and rebuild to find it, all in the practice terminal on the archive fixture.
You already know find: point it at ~/archive and it walks the whole tree, opening every folder to check each file, and prints the matches. It is always right, because it looks at the disk as it is this very second. You also met locate, which answers the same kind of question but far faster.
This lesson is about the one thing that makes locate fast, and the one price you pay for it. locate does not walk the disk at all. It reads a database: a plain file, written earlier, that lists every path the machine has seen. Reading a ready-made list is instant. Walking a disk is not. That single difference, a live scan versus a saved list, is the whole idea here.
The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. locate and updatedb come from a package called mlocate that is not part of a bare Linux install, so the practice terminals replay their real output here. On the real machine at the end of the module, the mission installs mlocate for you first.
Because locate reads a list instead of the disk, that list has to exist before locate can answer. Building it is the job of updatedb. It scans a directory tree one time and writes every path it sees into a database file.
This trick is older than it looks. The first locate shipped with BSD Unix in 1983, invented because disks had already grown too big to walk for every search. The version you will use, mlocate, was written at Red Hat in 2005. The m stands for merging: when it rebuilds the database, it reuses the parts of the old list that have not changed instead of rewriting everything from scratch.
You are going to build a small private database of just ~/archive, saved to a file in your home folder. Keep this command as one fixed unit; it is the machinery the snapshot needs, not the point of the lesson. Type it exactly and press Enter:
updatedb -l 0 -U ~/archive -o ~/archive.db
prompt: student@linuxcamp:~$ answer: updatedb -l 0 -U ~/archive -o ~/archive.db output: hint: Type it exactly, it prints nothing when it works: updatedb -l 0 -U ~/archive -o ~/archive.db
updatedb prints nothing when it works. Silence is success, the same way cd says nothing when it moves you. In that one command, -U ~/archive says scan only the archive, -o ~/archive.db says write the list to your own private file, and -l 0 lets you read that file back in this sandbox. You do not need to memorize the flags today; you need to see what they produced.
Nothing printed, but the important thing now exists. updatedb walked ~/archive one time and wrote every path into ~/archive.db. That file is a snapshot: a frozen photograph of what the archive contained at the moment the command ran. From here on, locate reads this photograph instead of the disk. Hold on to the word snapshot, because the rest of the lesson turns on it.
The database is not a hidden, magical thing. It is an ordinary file sitting in your home directory, exactly where -o told updatedb to put it. Prove it exists by listing it by name:
ls ~/archive.db
prompt: student@linuxcamp:~$ answer: ls ~/archive.db output: /home/student/archive.db hint: List the one file by its full name: ls ~/archive.db
There it is: /home/student/archive.db, a normal file you own. That is all a locate database is, a saved list of paths on disk. It sits beside your archive, not inside it, so scanning the archive again never disturbs it. When you picture locate working, picture it opening this file and reading lines, never touching ~/archive at all.
Now put the snapshot to work. locate reads a database, and because you built a private one rather than the system-wide list, you tell locate which file to read with -d (short for database). After that comes what you are looking for.
Ask the snapshot for every .conf file. A plain locate does not sort its lines, so pipe it through sort for a stable order:
locate -d ~/archive.db '*.conf' | sort
prompt: student@linuxcamp:~$ answer: locate -d ~/archive.db '*.conf' | sort output: /home/student/archive/config/.secret.conf /home/student/archive/config/app.conf /home/student/archive/config/logging.conf hint: Point locate at your private db with -d, then the pattern: locate -d ~/archive.db '*.conf' | sort
Three config files, instantly, and locate never opened ~/archive to get them. It opened ~/archive.db, the file you just listed, and printed the lines that matched. That -d ~/archive.db is the pointer to your snapshot: change the file after -d and locate would read a different list entirely. The speed you feel is exactly this, reading a list beats walking a tree.
The wider world of locate patterns, counting matches, ignoring case, matching a bare word anywhere in a path, is its own lesson. Here, every locate reads the same snapshot the same way, so the snapshot stays the star.
A photograph only shows what was there when it was taken. Your snapshot was frozen the instant updatedb ran, so anything created after that moment is not in it.
In the locate lesson you were asked to imagine a file the snapshot had never seen. This time nothing is imagined. You will create the file yourself, right now, and then catch the two search tools disagreeing about it. Make a brand-new empty file inside the archive with touch, the file-creating command from way back in the Manipulation lessons:
touch ~/archive/draft.txt
prompt: student@linuxcamp:~$ answer: touch ~/archive/draft.txt output: hint: touch creates an empty file and prints nothing: touch ~/archive/draft.txt
Silent, as touch always is, but the disk just changed. ~/archive/draft.txt exists now, and you know something the snapshot does not: it was born after updatedb took the photo. The disk and the list no longer agree, and you caused it on purpose.
Now interrogate both sources about draft.txt, one at a time, starting with the snapshot. Before you run anything, predict the outcome: the file is really on the disk, you just made it, but will locate find it?
locate -d ~/archive.db draft.txt
prompt: student@linuxcamp:~$ answer: locate -d ~/archive.db draft.txt output: hint: Run locate -d ~/archive.db draft.txt and watch it come back empty
Nothing. An empty line, even though you created draft.txt seconds ago. locate is not broken and it is not lying. It answered honestly from the snapshot, and draft.txt was not in ~/archive when updatedb took the picture, so it is not in the list. The list has gone stale, and this time you watched it happen.
Notice what an empty result does not tell you on its own. It could mean the file truly is not there, or it could mean the snapshot simply has not caught up. Same silence, two very different causes.
Here is the same missing file, asked a different way. find does not read a snapshot; it walks the live disk the instant you run it. So it sees the draft.txt that locate just missed. You already know find; this is only here to sharpen the contrast:
find ~/archive -name 'draft.txt'
prompt: student@linuxcamp:~$ answer: find ~/archive -name 'draft.txt' output: /home/student/archive/draft.txt hint: Point find at the live tree by name: find ~/archive -name 'draft.txt'
The live scan found it at once. Same file, same moment, two different answers: find said yes because it looked at the disk, locate said nothing because its snapshot predates the file. This is the whole reason both commands exist. find is always current but pays to walk the tree every time. locate is instant but only knows what its last snapshot knew. Neither is wrong; they are answering from different sources.
A stale snapshot has one fix, and it is the command you already ran. Take the photo again. Running updatedb a second time re-walks ~/archive, sees draft.txt this time, and overwrites ~/archive.db with a fresh list:
updatedb -l 0 -U ~/archive -o ~/archive.db
prompt: student@linuxcamp:~$ answer: updatedb -l 0 -U ~/archive -o ~/archive.db output: hint: The exact command from the start of the lesson: updatedb -l 0 -U ~/archive -o ~/archive.db
Silent again, and the snapshot is now current. updatedb overwrote the old ~/archive.db with a fresh photograph that includes draft.txt. Nothing about locate changed; you changed the list it reads. The very same locate -d ~/archive.db draft.txt that came back empty two steps ago would now print the path, because the snapshot finally caught up to the disk. That is the rhythm of locate: instant reads off a saved list, plus an updatedb whenever the disk has moved on and the list needs to catch up.
One more piece completes the picture. Every locate in this lesson used -d ~/archive.db, pointing at the private snapshot you built. But locate typed with no -d at all still works on a real system, because it falls back to a system-wide snapshot the machine keeps for the whole disk.
That system snapshot is built by the very same updatedb, just run for everything and saved to a standard location instead of your home folder. And it goes stale for the exact same reason yours did. The difference is who keeps it fresh: on most systems a scheduled job runs updatedb in the background, often overnight, so the system-wide locate is refreshed for you while you sleep.
This is why a file you created five minutes ago sometimes cannot be found with a bare locate, while an hour-old one can: the background updatedb has not run since you made it. The file is real; the snapshot is behind. The cure is always the same, rebuild the snapshot with updatedb, and the newcomer appears.
The training wheels come off. From here, no command is shown. You know both sources and how to read each one.
The archive holds some spreadsheets. Ask your snapshot for every path ending in .csv, in sorted order.
prompt: student@linuxcamp:~$ answer: locate -d ~/archive.db '*.csv' | sort output: /home/student/archive/reports/2025/data.csv /home/student/archive/reports/2025/metrics.csv hint: Point locate at your private db with -d, quote the pattern '*.csv', then a padded pipe and sort.
Two spreadsheets, straight off the saved list. The disk was never touched.
Now put the same question to the live disk. Scan ~/archive for names ending in .csv, sorted, without reading any snapshot at all.
prompt: student@linuxcamp:~$ answer: find ~/archive -name '*.csv' | sort output: /home/student/archive/reports/2025/data.csv /home/student/archive/reports/2025/metrics.csv hint: The live-scan tool takes the tree first, then -name with the quoted pattern, then a padded pipe and sort.
Identical answers from two different sources. That is no accident: you rebuilt the snapshot after creating draft.txt, so the list and the disk agree right now. The two tools only disagree in the gap between a disk change and the next updatedb. Fresh snapshot, same truth.
Last one, and it is the move that cures every stale list. Rebuild your private snapshot of ~/archive, saved to ~/archive.db, from memory.
prompt: student@linuxcamp:~$ answer: updatedb -l 0 -U ~/archive -o ~/archive.db output: hint: Three flags in order: -l 0, then -U with the tree to scan, then -o with the output file.
Silence, which you now know means success. You just recalled the whole machinery unaided: that exact command is the one you will reach for on any machine where locate cannot find a file you know is there.
Strip everything else away and one sentence remains: locate is fast because it reads a saved snapshot of paths, and a snapshot can go stale, so updatedb retakes it. Every command below is a move you made on ~/archive. Each one either builds the snapshot or reads it.
The locate and find rows are the whole contrast. find reads the disk, so it is never stale but pays to walk it. locate reads the snapshot, so it is instant but only as fresh as the last updatedb. When a locate result comes back empty, ask yourself first: is the file truly gone, or has my snapshot just not caught up? An updatedb settles it.
The sibling Search lessons drill the other halves of this toolkit: one covers find and its filters (-name, -type, -size, -mtime, and more), another tours the locate patterns and switches like -c and -i. This lesson owns just the mental model that makes sense of them both: snapshot versus live.
The practice terminal has shown you the rhythm: updatedb takes a snapshot, locate reads it in an instant with -d, and when the disk moves on you take the snapshot again. The empty result you saw was not a failure; it was a stale list, cured by one rebuild.
The Search module ends with one real Linux machine, and that is where you run these for real. In the Search capstone mission, a VM boots just for you on this same ~/archive fixture. The mission installs mlocate, then hands you objectives built on exactly this idea. You build a snapshot with updatedb, read it back with locate -d, watch a new file go missing, and rebuild to find it. One difference from here: the lab shows no commands. You read the objective, recall the move, and type it. That recall is what makes the snapshot idea stick.
Finish the other Search lessons, then go build the snapshot for real.
Practice The locate Database: Snapshot vs Live in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.