Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there an equivalent of the GNU locate command in Windows 7/8?

locate can take as input a file name and gives as output all the paths where files named similarly to input are, e.g.:

locate file-with-long-name.txt
share|improve this question
For those of us that don't know locate, can you describe what you want it to do? – Jay Bazuzi Nov 7 '12 at 13:47
@JayBazuzi I did even if it was admittently less than clear, edited to clarify and added sample output – Razor Nov 7 '12 at 13:56
What does "similar" mean? – Jay Bazuzi Nov 7 '12 at 14:11
You didn't say, but I'm assuming you mean GNU locate. I'll modify your question. – Jay Bazuzi Nov 7 '12 at 14:33
@JayBazuzi e.g. searching for index.htm also finds index.html – Razor Nov 7 '12 at 14:33
up vote 7 down vote accepted

No, there is not a Windows cmd or PowerShell builtin equivalent to Linux/GNU's locate command. However, functional equivalents include cmd.exe's dir /s as described by JKarthik, and these PowerShell options:

PS> Get-ChildItem -Recurse . file-with-long-name.txt

Note the use of ., telling PowerShell where to begin the search from. You can, of course, shorten when typing at the command line:

PS> gci -r . file-with-long-name.txt

I do this a lot, so I added a function to my profile:

PS> function gcir { Get-ChildItem -Recurse . @args }
PS> gcir file-with-long-name.txt

This allows wildcards, similar to locate:

PS> gcir [a-z]ooo*.txt

See help about_Wildcards for more details. That can also be written with Where-Object like this:

PS> gcir | where { $_ -like "[a-z]ooo*.txt"}

locate has an option to match with regexes. So does PowerShell:

PS> gcir | where { $_ -match "A.*B" }

PowerShell supports full .NET Regular Expressions. See about_Regular_Expressions.

You can do other types of queries, too:

PS> gcir | where { $_.Length -gt 50M }  # find files over 50MB in size

Performance of these approaches is slow for large collections of files, as it just searches the filesystem. GNU locate uses a database. Windows now has a searchable database, called Windows Desktop Search. There is an API to WDS, which someone has wrapped with a PowerShell cmdlet, here:, allowing things like:

PS> get-wds “kind:pics datetaken:this month cameramake:pentax” 

with much better performance than Get-ChildItem, and this kind of rich query (and awkward syntax). Also, note that curly quotes work fine in PowerShell, so no need to edit that sample when copy/pasting it.

Maybe someone will find (or write) PowerShell cmdlets that allow idiomatic queries to WDS.

share|improve this answer

For a PowerShell solution, try this:

Get-ChildItem -Filter "file-with-long-name.txt" -Recurse

This returns all files that match the given name in the current directory and its subdirectories.

The -Filter parameter accepts wildcards. If the current directory contains system files that you don't have access to, add -ErrorAction SilentlyContinue to suppress errors.

For more information, see Get-Help Get-ChildItem.

share|improve this answer
At the command prompt, I abbreviate -ErrorAction SilentlyContinue to -ea 0, for ease of typing. – Jay Bazuzi Nov 7 '12 at 14:59
This answer is better prepended with a warning about the huge difference between locate (which looks into a previously generated database, with the pro of speed and the con of not being instantaneously up-to-date) and Get-ChildItem. – sancho.s Dec 20 '13 at 17:02

You can use the following command on windows shell:

dir [filename] /s

Where filename is the name of the file you're looking for, and /s refers to include sub-directories in the search.

Update The following command with /B shows only bare format, exactly as required. And this seems to be a tad faster.

Do try:

 dir [filename] /s /B

Source: Windows 8 Command Line List and Reference

share|improve this answer
this is scarily slow compared to linux, but it does eventually find the file. Will mark it as answer if nobody else finds a faster alternative – Razor Nov 7 '12 at 14:00
Hey, /B displays in bare format (only the location of the file) and this seems to be tad faster. Do check. – JKarthik Nov 7 '12 at 15:48
The difference is that locale looks in a database (generate/updated by updatedb) and dir actually searches the full hard disk. – Joachim Sauer Nov 7 '12 at 16:49
dir/s is slow because it brute-forces the search (looks everywhere). It harks back to DOS (being a DOS command), which is why it operates that way. I suspect the only reason it still exists is as a fall-back in case your index database isn't adequate. – Ben Richards Nov 7 '12 at 17:50
This answer is better prepended with a warning about the huge difference between locate (which looks into a previously generated database, with the pro of speed, and the con of not being instantaneously up-to-date) and Get-ChildItem. – sancho.s Dec 20 '13 at 17:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.