Decent free file search tool for Windows

Nazo

2[H]4U
Joined
Apr 2, 2002
Messages
3,672
So this is probably one of the silliest problems to run into, but I use an alternate shell (a BlackBox build -- specifically bbZero right now) and one of the stupidest little annoyances is that I don't really have any obvious means of getting to the built in search tool. (If there is some method I don't know it anyway.) Theoretically a third party tool could actually be better given how basic the built in tool is, but, oddly enough I haven't had a lot of luck. Particularly since the best stuff is commercial (seriously? Someone can actually sell a file search tool? ... I'm not paying real money for such an incredibly simplistic piece of software that I rarely even use and I can hardly imagine many others doing so...)

Right now I'm using one simply called "Locate." Problem with it is it does a file database, so I must update the database every time (or let it run in the background updating itself) which is exactly what I don't want (I consider this to be a waste of resources -- I'll just wait longer the rare times I search, especially since I usually can narrow down the search a fair bit anyway so that it only searches a handful of directories or so.) More importantly, this doesn't get along with external drives unless I manually add them to the database before even searching... With this last one I actually just gave up and went to a Cygwin terminal and used "find | grep filename" (which is probably not even a remotely optimal way to do it in a Bash terminal, but screw it, it works.)

Seriously silly problem and I've been putting off for years even bothering to seriously look into this, but I guess it's time I finally get around to it.
 
Seems like that one requires indexing. I tried a search of a file I verified existed without it indexing and it failed to produce any results at all.
 
Windows has a built-in search tool but really you're going to have to allow for the indexing period no matter what tool you've going to end up using. There's simply no way a search tool can search everything (see what I did there?) instantly without having an index of the contents of files to search through - it's just not possible even with most powerful tools out there. You'd literally have to copy your entire storage into RAM to have that kind of access to information with those kinds of speeds.

If you enable all the indexing features in Windows and allow it to index all the contents of everything (yeah, yeah) it is quite fast indeed, it's always worked for me and never been an issue personally.
 
Windows has a built-in search tool
Can't get to it for the reason stated in the first post.

There's simply no way a search tool can search everything (see what I did there?) instantly without having an index of the contents of files to search through - it's just not possible even with most powerful tools out there.
This is patently false and I don't really understand why you're claiming it to be true. By your argument wouldn't the actual indexers themselves then have no index to refer to? If it were impossible to know the contents of a filesystem without referring to an external indexer then the indexers would have to refer to an external indexer which in turn would have to refer to another external indexer and so on into infinity. But, it's simple: all they have to do is look at the filesystem itself...

But don't take my word for it. I've already mentioned one way it can be done without an index. In *nix find with no parameters just lists all files (I'm sure there's a way to give it an expression to show what I'm looking for, but I couldn't figure out how to do that and go through subdirectories, so I just do find with no parameters. I don't really know regex.) I just pipe its results to grep which will only show things matching a search term. There are Win32 builds of these -- not just Cygwin, but MingW32/64 builds as well because they are super simple, super basic standard tools, so you can test this yourself if you like (even in a Windows command prompt the command line I specified should basically just work as-is as pipes work effectively the same in DOS/Windows cmd,) though if you use MSYS then it gives you a Bash shell anyway. (Well, if you're feeling lazy you can just grab the binaries and test that.)

BTW, the built-in Windows search tool does not require the indexing service. It benefits from it, but it will search without it just fine. Again, don't take my word for it. Disable the service and run a search yourself. (Don't worry, you can just reenable the service when you're done.) If you think with the service disabled the search tool is just referring to its (now offline) database, try searching an external drive it hasn't had a chance to index (load files onto a USB drive using another computer or something.)

You'd literally have to copy your entire storage into RAM to have that kind of access to information with those kinds of speeds.
Or just go through the file table one file at a time without any need to use any significant amount of RAM at all. Well, there are more optimal search algorithms (such as a binary search) that could be utilized, but I think they all just go in order without any special optimizations applied. I mean, even if you did load the entire master file table of a NTFS volume into RAM we're talking less than a gigabyte for a really big one (who doesn't have at least 4GiB of RAM these days?) but it would be exactly as fast as going through it without loading it into RAM (it reads from the drive at the same speed and the CPU work of the actual search itself is the same either way,) so there's no reason or benefit to do this anyway, but if you really really just had to for some reason it can be done. Actually, I wouldn't be shocked if system file buffers already load most of it into RAM anyway.


Now, one thing I want to be clear on. I said this in the first post, but I feel like you maybe missed it since you're implying I have a problem with waiting itself: I don't mind waiting. I don't need instant results. I rarely do a search and when I do it's never for someone demanding I find a particular file right now with a gun to my head. Often enough I just have the search running in a background while I'm doing other things, so it's really no big deal... And, again, as I said before, I usually narrow it down to a general vicinity (say a downloads folder or something) which speeds things up quite significantly since it doesn't have to crawl the entire filesystem but just a limited subset. You severely overestimate how long it typically takes though. Even in an extreme case on an external drive it's rarely more than a couple of minutes or so.
 
Last edited:
My answers stand. If you're that cautious about using system resources to do actual computing tasks such as searching for files, well, you've got other issues I suppose. If you know such better ways of doing things, by all means, break out an IDE and get started on creating the ultimate and most simply sophisticated search tool that's ever been created.

Then Google will buy it from you for $400 million and you won't have to worry about such things anymore. :)
 
If you know such better ways of doing things, by all means, break out an IDE and get started on creating the ultimate and most simply sophisticated search tool that's ever been created.
Did you bother to read a single word I said? I don't think "find | grep searchterm" is "the ultimate and most simply sophisticated search tool that's [sic] ever been created." I'm not asking for anything complicated. Actually, indexing is a significant extra layer of complication... You have it quite backwards here. I'm asking for something that simply searches in the simplest possible way without having to drop to a command line to do it. Such tools surely exist (probably many of them) -- it's just not that easy to find them since it's hard to exactly specify to a search engine "but not one with indexing" as that's generally in the fine print if mentioned at all.

If you don't want to help, that's fine. But please do not troll.
 
Nazo, it seems that many programmers have decided that the benefits of indexing outweigh any disadvantages, as it can be somewhat difficult to find a search tool that doesn't use a database.

It's kind of funny, really. Years ago before SSDs were mainsteam, it was a bit of a chore to find a good search tool that used an index (thus greatly speeding up search results). You'd type in your search query and wait for minutes as the hard drive crunched and clicked away trying to return results. Now that SSDs have greatly reduced the time that it takes to search for files, indexes are somewhat less beneficial but more common. :)

With that being said, there are a few tools that I have personally used throughout the years. It's been a while since I have used them since I am generally a fan of search tools that use indexing, but I saw your thread and hoped that I might be able to help. Check the product pages out and see if these appear to be more or less what you're looking for. Can always download them and see how well they work for you.

Agent Ransack From Gizmo's Freeware:"Agent Rasack is one of my favorites when I'm in a hurry. It is very similar to Locate32. It does not index your hard drive, but is still relatively quick."

UltraSearch "UltraSearch does not maintain an index which is stored on your harddisk, but achieves its speed by working directly on the Master File Table (MFT) of the NTFS partitions."

UltraFileSearch "This Utility does not use background Indexing, does not waste system resources and does not use extra space on the Disk."
 
Nazo, it seems that many programmers have decided that the benefits of indexing outweigh any disadvantages, as it can be somewhat difficult to find a search tool that doesn't use a database.
Here's the thing. It isn't all or nothing. As I already mentioned, the built in Windows one will do either or. It will use the indexing service if it is enabled and if it is not it will simply search on its own. And why should a search tool refuse even to function without an index at all? If the index is not up to date yet -- such as on a removable device -- this is actually a very significant disadvantage... Using an index to accelerate the process is perfectly alright, but relying on it solely with the assumption that it is perfect is fallacious. (Of note, an index will not always necessarily know about things like deleted files if it's not running as a system service.)

You'd type in your search query and wait for minutes as the hard drive crunched and clicked away trying to return results.
Normally it doesn't even take as many minutes as that might imply. More like one or two, tops. Especially if you narrow it down to a directory tree instead of the root of the drive (in which case it may be mere seconds.) Certainly not enough to be a real problem. I say this as someone who has run unindexed searches on laptops with 5400 RPM drives designed for power efficiency over performance.


Anyway, upon an initial quick test I think maybe Agent Ransack will work. I wish it had just a tiny bit more actual configuration (I don't need multiple tabs thus need no tab bar and I don't need an extra toolbar that does everything the menu already does, most of which I never need anyway) but it gets the job done and when I run a search for something I know exists, it actually produces results without requiring me to manually update a database, run a background service, etc etc. Well, I should try the others too to be sure, but this is very promising with only the most minor of annoyances.

So thanks.
 
Last edited:
Back
Top