Better file searching (on Windows) with a powerful, fast, easy tool
Note: This blog post is from 2009. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
Update in 2019: Though this post is from 2009, I still use and recommend this tool daily, so nothing about what I said below has changed (except of course where I indicate other informational updates in 2010 and 2013). And to be clear the tool is updated constantly and sports a modern interface (unlike the favored "old tools" of other folks, which may look the same as they did 20 years ago).
Ever need to do a search for files with some given text (or files of a given name) in Windows? I realize you may use a favored file editor to do it, or (worse) may rely solely on the anemic Windows find. I'd like to point you to an awesome and free alternative.
For years I've used a great freeware tool, FileLocator Lite, and I love FLL for several reasons (as does nearly everyone I show it to). Read on for more.
Beyond fast, effective, and easy searching, it also has a cool regular expression building wizard that may be reason enough to use the tool when you need to create a RegEx quickly. It's the freeware version of a commercial product, File Locator Pro.
(Update in 2010: Originally, the free version was only packaged under the name AgentRansack, which was a little scary-sounding for some tastes. The makers finally offered a rebranding of the tool under the name File Locator Lite, though they still also offer it as AgentRansack, being the same product. The makers just seem to have a fondness for the "old" name so are going with both.)
(Update in 2013: While I still recommend FLL most highly for nearly all search needs, I do want to add that if you're ONLY searching for files or folders by name, not content, then there is a potentially better (and still free) tool to consider for that need, called Ultrasearch. I use both at least weekly. See the added section at the end of this entry.)
Why I favor it over Windows Search
I do realize that the Windows File Find feature can be enhanced by using its available Indexing Service. I've never been a fan of that for various reasons, and many won't enable such (for good reason) on production servers. Yet you may need to search for files on such a server. FLL does its searching with little overhead, so it's absolutely safe to use on servers (and leaves no indexes behind).
(By Windows Find I'm referring to the feature available from the search feature in Windows explorer, or searching via the Start menu or via WindowsKey-F).
And I realize also that later versions of Windows do offer better text file searching, but it's still not as simple as it could be (if the first search doesn't find files, you're offered a chance to do a deeper search). FLL instead is incredibly simple to use, from the first.
And when compared to the Windows File Search feature, it's not only far faster but also DOES search for content in ALL file types. Have you ever used Windows find to search text in CFM files, and found that it never finds files you know it should? The problem is that it has (at least in some Windows versions) had an internal list of file types it WOULD search, and all others it will simply IGNORE. It also ignores files marked with the hidden and system attributes, which may not be expected.
Sadly, some people may not ever both to do such searching of files by name or content simply because the available tools are so poor. This one will change your mind!
Why I favor it over search tools in editors
Since learning of it in about 2004, I no longer use the find feature within editors to search across multiple folders anymore, whether CFBuilder, Eclipse, DreamWeaver, CF Studio, or various alternatives (including Sublime, Atom, VS Code, etc in years since this post). FLL
In my experience, FLL is just so much faster than those when I've tested things, whether searching tens, hundreds, thousands, or even hundreds of thousands of files. (I've even used it to search millions of files and it did not take hours to do the search. Of course, if you search a million files but tell it to only search for files of a given type, then it's really searching only those files--so when I say millions of files I really do mean millions of files searched.)
And unlike using your editor to search, FLL doesn't lock up your editor while it's searching away.
Other benefits
Again, it's really FAST! I find it can search gigs of content in just a few moments--yet it DOES NOT rely on indexing the content in any way.
Another great benefit it has over the other more traditional search approaches is that while the left pane is showing the files it found in its search, the right pane shows (for any file you select on the left) the lines WITHIN the file that matched the search. You don't even need to open the file(s) shown in the left pane, if the results on the right pane may answer your question/show what you were searching for. (Curiously, the screenshot I obtained from the web site above shows these result panes as above and below each other.)
And yes, in some editor search tools, the search results pane allows you to click on a result in order to open the given file--perhaps even at the location where the search result was found, but this approach in FLL to just show them on the right (as each result file is selected) is just much simpler and more effective, I think.
Perhaps most powerful, it also integrates with the Windows Explorer interface, so it's easily reached by a right-click on any folder to search that folder and its children.
Bonus Regex Feature
As I hinted above, beyond searching, FLL is also great for its really nifty regular expression feature, to help build regex's declaratively (with a wizard-like interface). I find myself opening it just to create a RegEx when needed. More than that, there is also a useful "test" menu option where you can enter a RegEx, and some text against which to search, and it will show what the regex would find in that text. Very handy.
Check it out
Everyone I've shown it to has been impressed. I hope you will at least check it out.
You can see screenshots of 3 main parts of the interface in use (including the regex wizard and results viewing aspect) at the site.
Other tools
I should also mention that this is indeed just one of dozens of such file/find tools that exist, for Windows, *nix, etc. (yes, including grep tools for both OS's). I do list dozens more in a category for these tools at my CF411 site, which lists over a thousand tools and resources of interest to CFers.
Enjoy.
One more update
Here's one more update I'd like to make: if you may be searching for files (or folders) ONLY by name and NOT by file content, then there's a still-better free tool for Windows that I'd recommend: Ultrasearch, from jam-software.com, the same people who make the also excellent and powerful TreeSize tool for analyzing your disk space usage, per folder.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
Some tips for ppl that are not that great with regex. to look in just cfm and cfc files use
(cfm|cfc)$
If you are looking for a file with extension use myfile\.ext u need to escape the dot
Of course there are also the alternative file content indexing engines that have existed over the years, such as Google Desktop search, Copernic, etc., which also index your entire drive (or whatever you tell it to do or not do).
Certainly, if one is willing to have such an indexing service running, scanning your files all the time (or whenever the engines do), then using such search tools will be faster. (I do point out those alternatives at the bottom of the CF411 entry above.) As I also said in the entry, some people just don't want to have such search engines running all the time, especially on servers.
So Todd, is that perhaps why your searches are faster?
For the record I did a simple search in my 'Documents' folder for items containing a certain string. It ran probably 2-3 minutes before I cancelled it and it found 4 or 5 results. Oh, and it seemed to have problems displaying a snippet if the result was found in a ZIP file. Is that expected? I just got some binary output...
As for AR not displaying a string within a file in a zip, I just checked and see that that's supported in the commercial version (File Locator Pro, as I'd mentioned). Here's a comparison of them: http://www.mythicsof...
I'll just say again that it's a tool I benefit from daily. Maybe I don't search binary and zip files as much. I can say that every time I've worked with a customer providing CF troubleshooting support, and they needed to search through either their code base (perhaps to find things like where clientmanagement is enabled for any applications) or a raft of log files (such as to look for outofmemory errors), this tool has worked faster than the alternatives they've had.
Still, thanks for your perspective, Todd. No doubt different people will have different search requirements. Hope folks who find this will try for themselves. It's free, it installs in a minute, and I find it to be very fast and effective.
But if you'd update a file, and search for that content, and it finds it, then nope you're not using the index. Just wanted to check to make sure the comparison was not benefiting from the index.
Again, though, if you happen to try doing a search of CFML code or logs, I'd be curious if it's any faster for you. I meant to say also that most times when I'm helping folks on their servers, they're of course running 2003. :-)
http://www.ghisler.c...
First, I see that TC does a whole lot more than AR, and is really a replacement file manager. So granted it may add features that make it preferred for some over a tool dedicated only to search, even if it didn't t perform searching as well (and I'll show that in my experience it does not).
I also see that TC is not free, but shareware (30 day trial), with an annoying popup at startup during the trial that makes us choose a randomly changing number. FR is totally free.
More important for me, I notice also that TC doesn't make itself available in the Windows Explorer context menu for directories, which is a show stopper for me in terms of using it when I need to do a search. For me, though, I don't want to have to open the tool and drill down to the directory to search. Again, if one views it as a replacement file manager, then I suppose it makes sense that it doesn't integrate that way.
Since others may not be so concerned with those issues, I proceeded with the search comparison.
I did 3 tests, one doing just a search for all files (with no filename or content pattern), then one searching for all application.cf* files, then one searching all those for the string clientmanagement (yes, I realize one could set that in a cfapplication tag in any file, so searching only the application files isn't complete, but let's ignore that for this test).
I ran the test against a code directory with 58k files (a total of 1.7 gb in size). That may sound like an outrageous number of files, but often when I help CF customers doing troubleshooting, they really do have that many files that need to be searched (which may be because they keep various versions of code in different directories, or they may modify versions slightly for different clients, etc.) Let's not debate the pros/cons of such an approach and possible alternatives. Again, that's not the point of the exercise.
FWIW, I ran the test on my Vista laptop (dual core t2600 @ 2.16 Ghz, 4GB Ram). Finally, in order to avoid the possibility that OS caching helped the test of the second tool, I repeated the tests in reverse order and am reporting the average.
So in the first test, just finding all the files (no pattern for name or content), AR took about 2 seconds, while TC took about 42. Granted, it's a lot of files. Still, both tools did basically the same thing, simply pulling the file names into a display. Interestingly, despite AR being so much faster, TC's search results pane just showed the filename and path, where AR showed name, path, size, type, and modified date, and those cols were of course sortable.
For the second test, finding all application.cfm files, things improved for TC. AR still took just 2 seconds but TC improved to only 7 seconds on average.
For the final test, searching those files for the string, AR increased to an average of 13 seconds, while TC interestingly averaged the same 7 seconds that it had with no search string.
On the surface, TC is just about double AR and yet both did a good job. But most distressing of all (in terms of using TC for searching) is that TC just shows the results in a pane of filenames. That's it. From there you can open each one, but as I mentioned in the blog entry AR lets you single-click a found file to have it show (in a right pane) what lines in the file matched the search string. That's just not possible with TC (even with its "feed to listbox" feature, which populates its left pane of files with the found files. There's still no mechanism to show just the lines that had matched the search.)
So again, I'll say that TC may offer value as a file manager replacement, and with its 2-paned interface, it clearly seems oriented to those who like to do operations against 2 sets of similar files (copy, move, compare, etc.) That's just not something I need to do, myself.
So I'll say thanks, James, and enjoy, but it's just not a suitable alternative for AgentRansack to me. Still, perhaps others will enjoy it. Cheers.
Regarding the list view, when viewing the results from TC, press the "Feed to Listbox" button to view/sort multiple columns. To view more than the default path and filename, you can create a "custom column layout" and select from over 25 different file attributes for your columns (versus the 5 static columns avilable in AR.)
TC can search files based on system attributes and even allow you to search for only directories with certain names (versus only files and directories in AR.)
TC finds duplicate files based on same name, filesize and/or contents. (AR does not have this capability.)
TC searches within archived files (ZIP, ARJ, LZH, RAR, TAR, GZ, CAB and ACE). (AR does not have this capability.)
TC has a quick viewer. Press F3 and view the contents of any file and toggle text, binary, hex, image, HTML, unicode and UTF-8 views by pressing the 1-7 keys. (The only way to view the contents in AR is to initially search for "containing text" otherwise it only shows the name of the file in the preview pane.)
TC has the ability to search based on additional file metadata using free plugins, I can use multiple AND/OR search criteria like "image width > 400" OR "ID3 Artist = U2" OR "PDF # of pages > 20" or "MP3 bitrate > 160". Check out the list of content plugins here:
http://www.ghisler.c...
TC allows you to save your searches and easily select them from the tab (w/syntax preview) without having to fumble for the "File | Open" dialog box and locate the search criteria file. (I guess you could use AR to search for all SRF files.)
My favorite feature on TC is bookmarking directories. I'm able to quickly change to different server/drive/directory combinations in 2 keystrokes... I use the "Quick Search" feature to automatically locate (or filter) files that start with the characters I'm typing (similar to autosuggest). I also customize the toolbar and have NotePad++, TeraCopy, WinMerge and Paint.Net easily accessible so that I can drag-and-drop files on the buttons to launch without having to navigate to Start or desktop shortcuts. (I also use many AutoHotkey macros.)
Regarding speed, if you are searching filenames locally and need to use regex, "VoidTools Everything" is the fastest (and it's free). "Everything" took less than 1 second whereas AR takes about 9 seconds when searching a local sub-directory for "*.cfm". It has the ability to view/sort by 9 different attributes. (Note: This is an Explorer-plugin and works with Total Commander too.)
http://www.voidtools...
Regarding the $30 license, it may installed on as many computers as desired, as long as it is used by only one person at any one time. Don't let the price tag or a longer wait on a "filename-only" search stop you from checking out Total Commander as it is much more than a file search tool with regex capability.
Yes, as you note, AR does do a presumed wildcard search, so that it finds files whose names and extensions match any part before or after the provided string (so application.cfm might find renamed variants like xapplication.cfm or application.cfmx). That actually leads to it finding more files, and since it was AR that was still faster, I didn't bring it up.
As for the additional TC advantages you point out (search by attributes, search within archives, file viewer, plug-in support, saved searches, etc., and running from a USB in your earlier comment), I'll note again (as I did to Todd above) that these (and many more) are in the commercial edition of AR. So again it seems AR has an edge in being free, as long as one is happy with the features and performance it does offer. (You mention bookmarking and toolbar access to other programs, etc., but again those are file manager features, not search tool ones.)
As for "Everything", well, I see that it's both based on indexing (which I've said from the beginning that I'm not interested in, as I need a tool I can install on a production server at a customer site and know that it will not leave any footprint), but more important, I see that it does NOT search file content. I know you said it's for "searching filenames locally", but I wanted to clarify that for readers. But if it has value for you, or may for others, then thanks for sharing it.
You end by suggesting one not ignore TC if needing more than just file search. Just to be clear, I've never suggested otherwise. I've only said from the beginning that I'm pointing out a search tool and its advantages over other search tools.
Finally, as for your additional comment, that (limiting search depth) does seem to be something not in even the commercial edition. I've just asked them about that, as I agree it's a nice feature.
Hope others may be enlightened by this back and forth.
Regarding another search feature, I just tested TC with FTP... I logged into a FTP server and was able to perform both a filename and content search! (I had never tried this before.) This would be a pretty handy feature for any developer to have. While viewing the FTP directory, I clicked on the "Edit" button, edited a file, exited and Total Commander automatically prompted and uploaded it back to the FTP server.
I know I was throwing out additional features that are not found in file searching-only programs. As a developer I tend to do much more than just search for files and don't like having to install multiple programs. This is an all-in-one software solution that saves time and can replace multiple programs... and, yes, it's not as fast as AR for this single dedicated task but it still performs the same task. Please note that the shareware trial does not expire and the impact of having to press "1, 2 or 3" is only once at start-up.
I realize that many stay "stuck on" Windows Explorer simply because they know of nothing better. In my case, it's just that I haven't needed the features that other tools offer over it. But if you've motivated some here to look at them, great.
Indeed, I will note that I already pointed them out in my discussion of Search tools at CF411. In the the next to last bullet of the #filefind section, I even point to a link comparing file managers there.
Still, I will make a note to add such a section and TC will be there, you can be sure. :-) No promises for how soon that will happen, though. I wouldn't want to list just one, and again I'm not that motivated to go find and list others. If you or anyone else wants to offer them, and especially formatted so I just drop the HTML into place, I'll be glad to do it.
That may lead some to wonder when I will open the cf411 site up to be more of a user-editable wiki. It's in the plans, and sooner rather than later. I'd love to have RSS feeds from additions, as well as a place to add comments, ratings, etc.
As for adding TC to other categories per its available plug-ins, I don't know. That's a slippery slope, since it's about the plugins. Which should I list then, the tool itself or the plugin? Could just be more confusing than helpful. But let me know if you think otherwise. And if you do, then feel free to name the category and specific plugin and its url, and I will add them for you.
Yep, great to hear that TC offers FTP search. Better still to see that you only realized it after this interchange. Glad if it was useful for you. :-) I don't see AR or its commercial alternative offering it, so that's definitely a point in its favor--not that we're keeping score, of course! :-)
As for your final points, sure, I leave them for others to consider. Again, I'm not motivated myself, as I just don't find myself needing what it offers, but I don't regard that as a measure of the value of what you've offered. :-) And now that it's installed on my machine, we'll see if I might start using it more. But until I lack something that it offers, I have to admit it's not likely. Hey, that's the way it is with tools. We can lead a horse to water... :-)
Best Regards
As for Lookeen 10, that's indeed interesting. I see that only this latest release now runs as a separate desktop search tool, unlike previous releases which were a plugin for Outlook. As such, I am wondering how much better it will be than FLL, which is a VERY mature product which I find it lightning fast and excellent at its job--indeed better than any other file search tool I've used. Still, I'll give the Lookeen trial a shot, since I do use outlook also. Perhaps its dual benefits may benefit me.
With your tool (I'll say that since you brought it up, whether you are associated with the vendor or not), not only does it require building of an index (which takes a LONG time), but the initial configuration of Lookeen does NOT index the C drive. It presumes only to index Outlook (PST files). Clearly, though there is now a desktop interface, and an option to choose to index a hard drive, it's clearly still its intended use.
And indeed, as I contemplated enabling its indexing of my C drive, I wondered "how large would that index be? and how long would it take? And would it be indexing all the content in every file? Is this really only intended to index text documents (so perhaps something like one's "documents" folder only?)"
For instance, I told it only index my Outlook resources. Holy smokes. Now 4.5 hours later its status and logs indicate its done only a fraction (much less than 1%) of what is in Outlook for me. I can't imagine how long it will take to finish. I'll report tomorrow or in coming days. And I can't imagine how long it would have taken to search my entire hard drive!
I'll leave your and my comments here, and if you want to point someone from the vendor here to offer thoughts, I'll welcome them. If I've somehow gravely mistaken, misunderstood, and/or misrepresented things regarding Lookeen, I'll retract or modify my statements.
Otherwise, I'm inclined to think that this tool is not at all in the same class as FLL (doing what this blog post was about, "better file searching".)
Guess you started an index, and it's still running! :)
I'm going to give FLL a spin. I haven't been too impressed by other options (i.e., can only recall dnGrep by name at the moment) and Window's search functionality SUCKS.
It sounds like you didn't implement any limit to the file name (extension, part of name, etc.) That would mean it would indeed look at EVERY file. If you could limit it at all, that can help. It supports multiple criteria, separated by semicolons. It also supports limiting by date, which could also reduce how many it would search against. Just depends on your needs, of course.
But I will say that when I set it to search my \windows folder, with 172k files and 30g of content, it did what you experienced--if I gave it no limits but a string to search for.
If instead I limited the filename field to: *.ini;*.bat, then it took only 6 seconds to search that same folder of 172k files.
I myself always use it first. The only time I'd use the Windows search was for search only by content, and against a single folder (or some small number of subfolders) and where I knew Windows WOULD find it. :-) Given how Windows only looks at files with a given small subset of file extensions, those situations where it WOULD find something are pretty rare. But hey, different strokes. :-)