Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .