Notes on Google Desktop

Google Desktop, the Google-made search utility for your computer, is finally out for the Mac. I've been playing around with it, putting it through its paces, and comparing it to Spotlight. Here's what I've found so far:

1. Google Desktop is much, much faster at searching than Spotlight. Spotlight took nearly a full minute to search the term "test" on my computer (that's measured from the time I hit return in the search bar to the time the pinwheel stopped spinning). Google Desktop was nearly instantaneous at returning results. I found both sets of results about equally useful — or useless, depending on your perspective.
   
   Spotlight Search Results: Slow and Useless
   (click image for larger view)
2. Google Desktop also returned fewer results than Spotlight. I'm not quite sure why this is so. My guess is that Google Desktop searches metadata and/or file contents differently than Spotlight. But who knows? I've often wondered how Spotlight determines what results get returned, and how relevancy is determined. It's mysteries like that that make these things perhaps less useful than they could be. I know how to optimize my web site for Google's internet search engine, at least to some extent, because how Google searches the web is not completely opaque to me. I do not know, however, how best to save my local data to optimize it for searching via Spotlight or Google Desktop. So my results tend to vary. The nice thing about Google Desktop, though, is that I at least don't have to wait 50 seconds to see my useless results returned. I get them instantly. Yee-haw.
   
   Google Desktop Search Results: Fast and Useless
   (click image for larger view)
3. Spotlight stores its index files on a per drive basis, which is smart: index your drive on one machine, it's indexed everywhere. Spotlight's index files are also really small. Google Desktop, on the other hand, creates much bigger index files than Spotlight, and those index files are all stored on the root drive (in /Library/Google/Google\ Desktop/Index/). This is bad for two reasons. On the location side of things, if you move, say, a firewire drive to another computer with Google Desktop, that computer will have to re-index the drive, and that index will always be out of sync with the ones on other systems, causing Google Desktop to constantly index external drives. On the size end of the equation, since the Google Desktop index is entirely on the root drive and can get quite large, it is quite possible, given a large quantity of data and a relatively small root partition — like, say, on my system — for Google Desktop's index files to completely fill your hard drive and lock up your system. Yes. This did happen to me. Thank you for asking.
4. Google Desktop also shows you other useful information right in the list of search results, which is nice. Info like the file path and a preview of the document's contents appear right there in the search window.

In terms of functionality, though, I like Google Desktop about as much as I like Spotlight, which is to say, not all that much. Mainly because I just don't get very useful results. There are some interesting features that Google Desktop offers in terms of Gmail integration that I've yet to try. These might add some appeal to the program. But as far as searching my local system goes, thus far even Google has yet to make a desktop application that rivals its internet search engine. Seems strange that searching local files is a harder nut to crack than searching the internet. But I guess it is after all.

UPDATE:
First off, I meant to mention that the initial indexing for Google Desktop took a very long time. I'm not sure how much because I ran it on my work machine and let it go all weekend long. Judging by the size of the index when I left the machine versus the final size, I'd guestimate it took roughly 24 hours. Very rough estimate. And bear in mind that I have probably around 1.5 to 2 terabytes of data.

Today I find that Google Desktop is hogging my CPU. I get a big performance hit whenever I'm doing large file writes to disk, which is understandable though hardly forgivable. Times like these the processor can hit near 120%. So, for instance, a file copy involving many files will cause my Quad G5 to bog down noticeably.

Google Desktop: Processor Hog
(click image for larger view)

In addition, since Google Desktop is apparently pretty damn slow about indexing, said file copy will cause Google Desktop to start indexing again, which makes its processor usage hover between about 50% and 90%. Google Desktop's indexing process is both slow — far slower than file copies — and processor intensive — to the point of making other apps run noticeably slower. I'm uninstalling it now. I have work to do.

That was fun while it lasted.

Scripts Part 7: Contextual Menus with Automator

Recently, for some odd reason, there has been a spate of solutions to the problem of creating new files in the Finder via a contextual menu. One involves a contextual menu plugin called NuFile. Another involves installing Big Cats Scripts and linking it to an Applescript. But honestly — and I'm surprised someone else didn't think of this first — when faced with simple contextual menu tasks, these days my first thought is to look to Automator.

And by golly, that's just what I did. Here are a few Automator workflows that do, more or less what the afore-linked methods do. To me, the advantage of the Automator approach is that you don't need to install anything. It's all baked in. Which means you don't ever need to update anything either. Nice. Simple. And, yeah, kind of the whole point of Automator.

So here you go. Maybe someone will find this useful, if for nothing other than as an exercise in creating contextual menu functionality with Automator. Or skinning a cat multiple ways. Or something. To use this, download the .zip file, unzip it and place it in:

~/Library/Workflows/Applications/Finder

NewTextFile Workflow

It should become active immediately.

Also, here are a couple variants. One will create a text file, and then open it in TextWrangler (if you have TextWrangler, and if you don't, go get it now); the other creates a Word document, and opens it in Word. I'm far to lazy to completely duplicate the functionality of NuFile. But if you examine these workflows, you can at least see now how that would be possible (in fact, fairly easy) to accomplish.

NewTextFile Workflow Variants

I actually think it would be great if Apple made it drop dead simple to create true contextual menus for the Finder. Fortunately, Automator gets us pretty close.

Oh, yeah, and since this is technically script writing, and since I haven't posted to that series in some time, we're gonna go ahead and call this a Script Sharing post. Deal with it.

Right. Good night.

UPDATE: Revised March 31, 2007, 3:00 PM

Stephan Cleaves has added yet another implementation of this idea. He's using a combination of Automator and AppleScript. I certainly think his implementation is better than mine in a few ways. Certainly more full-featured. It will prompt for a file name, for instance, and takes pains not to overwrite a preexisting file with the same name. Nice. But we're taking very different approaches to the same idea (his version places a file in the front-most Finder window, my version places it in the right-clicked folder), and he was confused by my approach. After speaking to him via comments on his blog, I realized that some clarification as to how my workflow is actually constructed might be in order.

Basically, my workflow takes the folder selected in the Finder as input and assigns that input to the variable "$@". That variable and the for loop in my workflow are automatically generated by Automator when you select “as arguments” from the “Pass input:” field in the “Do Shell Script” action. It’s how you get the context (the selected folder) passed to the script. Apparently Automator takes “$@” as the variable for “the folder you just selected” whenever there’s no input from a previous action. This was something I learned while fiddling around with all of this, and it's really my favorite part. The coolest thing for me here, really, was figuring out how to pass the context — i.e. the right-clicked folder — to an Automator "Do Shell Script" action. This opens up worlds of potential.

Finally, as I said, the for loop in the action is auto-generated by Automator. The workflow will work almost as well with the simple script:

touch “$@/NewText.txt”

Using the for loop, however, allows you to create a new text file in multiple folders by selecting said folders and running the workflow.

It's really kind of amazing how many ways there are to do this. Wow. Fun stuff.

Broken Downloadable Installers

In the past it's always been possible to save a copy of updates downloaded via Mac OS X's Software Update application.

Software Update: Keep it Handy
(click image for larger view)

Recently, however, certain Final Cut Studio updates will only install via the Software Update mechanism. You can download the updater, but it won't install. For instance, the version 5.1.4 update will download several packages to my hard drive.

Downloaded Packages: Completely Useless in this Case
(click image for larger view)

And I can launch the Final Cut package installer, and it will open in the Installer application. But the splash screen gives me my first hint that something is not right.

Installer: Uh-Oh
(click image for larger view)

I can even navigate to the "Select Destination" screen of the installer, but here I am told that this update can only be installed via Software Update.

Installer: New and the Opposite of Improved
(click image for larger view)

To add insult to injury, even though I've already downloaded the installers, Software Update, once quit, needs to download them all over again. Lame. Painful. Awful. Installing this 39 MB update on my 25+ Macs will kill my network. Guaranteed.

Software Update: But... I Just Downloaded It...
(click image for larger view)

The ability to download software updates for later install — or reinstall — is a really wonderful function of Mac's Software Update mechanism, particularly from a systems standpoint. It's sad and more than a little scary to see it not working on certain, specific pieces of software. Here's hoping this trend does not continue.

Replica Reset Voodoo (That Works!)

So today, after downgrading my master server to 10.4.7, I kept getting an error on my replica. So I decided to reset the replica by demoting it to a "Standalone" role, and then re-promoting it to the "Replica" role. But even after doing this, the error message persisted. The message was telling me to check the logs at:

/var/run/openldap-slurp/replica

and doing so did reveal errors like:

ERROR: Type or value exists: modify/add: memberUid: value #0 already exists

The solution was to again demote the replica to standalone status and then archive all the files in:

/var/run/openldap-slurp/replica

to anywhere else. I put them in a folder called "old." Just get 'em out of the way. Once this was done I was able to promote my replica without receiving error messages.

Yay! That wasn't too bad.

Oh, and you may be asking yourself how I knew to do this. Well, to be honest, I don't really remember. I just know that at some point in the past there was a problem I'd had with a replica and it was caused by stale files. So, since my ultimate goal was to start from scratch, I just got everything out of the way. And lo and behold. It worked. Sorry for the voodoo explanation, though. I wish I could be more explicit. Hell, I wish I fully understood what I was dealing with. But I don't. And, though it pains me to say this, I don't have time to figure it out.

But y'know? I'll take the cure even if I don't know what caused the disease.

Mac OS X Server 10.4.8 Breaks Windows Quotas

It's great to finally have something systems-related to post about amidst the endless bureaucracy that fills my days lately. Of course that means that — yup, you guessed it — something broke. But hey, that's what it's all about. Well, that and the fixing of said brokeness, of course.

So we recently discovered that our Windows clients were suddenly, and without explanation, able to greatly exceed their roaming profile quotas. In fact, looking at the roaming profile drive showed users with upwards of 25 GBs in their roaming profiles, which have quota limits of 50 MB. Not only that, but further testing revealed that Windows client machines wouldn't even complain if they went over quota. Any SMB connection to the roaming profile drive could exceed the quota limit without so much as a complaint from server or client. AFP worked. UNIX worked. But quotas were ignored over SMB. What the fuck?

For three days I've been trying to track this problem down, testing all sorts of quota scenarios and SMB configurations in between meetings and meetings and more meetings. Eventually, when I can't make headway on a problem, I start thinking it might just be a bug. So I started poking around in the Apple Discussions, and I found one and only one complaint of a similar nature: 10.4.8 Server with broken quotas on Windows. Had I recently done a system update that perhaps broke quotas?

So I started thinking about what in a system update could break such a thing. How do quotas work? There is no daemon. A colleague suggested that they were part of the kernel. Had I done anything that would have replaced the kernel in the last month or two?

The answer was yes. Over the winter break I had decided to update the server to version 10.4.8. Upon realizing this I began to strongly suspect that Mac OS X Server 10.4.8 contained a bug that broke quotas over SMB. Fortunately, as is often my practice, I'd made a clone of my 10.4.7 server to a portable firewire drive before upgrading. Testing my theory would be a simple matter of booting off the clone.

Sure enough, after booting from the clone, quotas began behaving properly on Windows clients again. Because I had the clone, reverting the 10.4.8 server back to 10.4.7 was a simple matter of cloning the contents of the firewire to the server's internal drive and rebooting. Voilà! Problem solved!

From now on I think I'll hold off on server updates unless I really, really need them. When it comes to servers, I think the old adage is best: If it ain't broke, don't fix it.