Google Experiments With Local Filesystem Search
Teoti writes "No, Puffin is not the next name of your favorite email client, but, according to the New York Times (NSA reg. req.), the project codename for a new Google search application coming directly into your desktop, that will let you search your local filesystem efficiently. This is different from, but complementary of, the Google DeskBar that already lets you search the Web. The article also gives a few words on the end of the stand alone browser in Longhorn."
Click here for CNET version.
Hmmm.
X1 seems to be the most popular one out there.
DiskMeta, they had this project in beta for a while, the Windows product went into relese just last week, the site says
DT Search, I remember their ads in bunch of computer magazines, although have never used them myself.
EFS, found it on download.com, supports MS Office and PDF as well as other formats.
No-Reg Link
Your hair look like poop, Bob! - Wanker.
If you have followed Microsoft developments around Longhorn you might have noticed that search is one of the top priority features that microsoft is going to integrate directly into the operating system. So once Longhorn is released Microsoft would become the biggest competitor to Google's search applications on the web as well the desktop(with this application)
Search is the next big thing on which a lot of players are concentrating and Microsoft entering the field has skewed the competition towards the desktop and everyone including Google is preparing for the battle.
It works a lot better when you enable indexing.
Or so I'm told. My personal experiences with allowing the Windows Indexing service to run in the background have been that it's more trouble than its worth. Yes, on the rare occasion that it's actually -not- indexing when I search, the search is blazingly fast (compared to a non-indexed search).
But if the index is currently being modified, then the Windows search feature can't use it. Period. So when you search, you get the text "Windows is currently building an index of the files on drive C:" and it falls back to the regular, non-indexed search. In addition, the indexer consumes massive amounts of RAM while indexing, so a search run when the index is being modified ends up being about two times slower than usual.
It also doesn't seem to be able to tell when the user is idle. No amount of tweaking seems to fix this, without leaving you with a days-old index. If the index is complete, but you've saved a file since it was completed, that file will not show up in the search at all. I've had it kick on while in the middle of working on something else so often that I finally just turned it off entirely and have resigned myself to slow(er) searches in Windows.
In the interest of fairness I will say that the search seems to work quite well when searching a remote server that is running the indexing service. But running it locally is just a pain.
End of lesson. You may press the button.
Well, first this idea is part of Microsoft's WinFS plans. The idea with WinFS was partially born when Microsoft developers realized that major parts of the web can be searched faster than a user's hard drive. It will be interesting to see how this application will collide with Microsoft's plans, that's for sure. It's basically fast searches and enhanced metadata support that are the key parts of WinFS, which is in turn a key part of Longhorn.
Second, an indexing software that does the same thing is already available today and worked very well when I tried it out. It's actually almost perfect, except for the fact that it causes occasional hard drive thrashing as it tries to keep the index up-to-date. This is unfortunately a rather major downside, but if you can bear with this, you'll get literally instant file searches on your entire hard drive -- it narrows down the possible matches as you type each letter. It even indexes file contents for small files. I'm talking about X1.
Beware: In C++, your friends can see your privates!
As a developer trapped in windows I find this little tool incredibly usefull.
"I can not bring myself to believe that if knowledge presents danger, the solution is ignorance" - Isaac Asimov
find and grep are oders of magnitude slower than the inverted text index techniques that Google uses.
See Lucene for a good open source inverted text index search engine.
I wish a could beat the creator of google-watch.org and every person who ever linked to it with a gigantic clue stick.
First of all, the creator of google-watch.org has a really big axe to grind with Google.
Second, HTTP is a stateless protocol. If you want a user's preferences to to persist within a session you need to use cookies or attach a lot of state information to each GET/POST request. If you want the preferences to persist after you close and re-open your browser you have to have the user log in every time and store the prefs on the server or store the prefs on the client side in a cookie like Google does. This simple fact seems to fly right over the head of google-watch.org and their ridiculous cookie conspiracy theories.
But hey, we've been over this in every Google story since the anti-Google FUD crowd started coming out of the woodwork. Here's a thought: if you really need a tinfoil hat then disable cookies, don't use Orkut and sleep better at night. But please stop subjecting people to google-watch.org FUD.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Create HKEY_CURRENT_USER\Software\Microsoft\Windows\Curr
You'll have the old windows 2000 search dialogue.