Bugs & Fixes: Dealing With CPU Overloads, Part Two

Today's Best Tech Deals

Picked by PCWorld's Editors

Top Deals On Great Products

Picked by Techconnect's Editors

Last week, I described a situation where the SyncServices process begins eating up so much of the Mac's resources that the Mac's overall performance slows to a crawl.

While working on the article, I recalled that I had previously covered a similar issue with a different process: mds, used when Spotlight indexes a drive.

Before I finally close the book on this topic, I want to return to the mds matter. In the specific case I cited, the symptoms were precipitated by an unneeded and unwanted indexing of a cloned backup of my startup drive. A quick work-around to stop the indexing is to add the backup drive to Spotlight's Privacy list.

The problem is that the backup drive would mysteriously disappear from the Privacy list periodically (especially so after restarting the Mac). Indexing would then begin again--until I re-added the drive to the Privacy list. A reader comment pointed my way to the explanation for this annoyance.

A cloned drive, by definition, copies over every file and folder on the original drive. This includes an invisible directory named .Spotlight-V100. This directory contains, among other things, files that determine whether or not indexing is enabled for the drive and whether or not the drive is in the Privacy list. The result is that, when you backup a Spotlight-excluded cloned drive, its index status reverts back to that of the original drive. When you restart the Mac (if not sooner), the drive is again indexed by Spotlight.

This is not a new issue. It dates back to Tiger, although it remains even in the latest versions of Leopard. A search of the Web reveals several suggested solutions.

One suggestion is to disable indexing by modifying the _IndexPolicy.plist file, located in the Spotlight-V100 directory. As far as I can tell, this is a Tiger file that no longer exists in Leopard; the indexing status is now maintained in the VolumeConfig.plist file. You can use Terminal to make the needed change, either via the mdutil command (-i off option) or the sudo defaults command (to directly modify the .plist file).

Another option is to add a .metadata_never_index file to the cloned volume. The shareware utility Spotless can easily do this for you.

The problem with all of these solutions (and the reason that I haven't bothered to give the precise details here) is that they all may ultimately fail. Again, they typically work only until the next time you clone the drive and the changes you made are replaced by the settings on your original drive.

The only sure and hassle-free solution is to use a backup utility that can retain the desired Spotlight settings on your cloned drive. SuperDuper is one such utility; there may be others.

Overall, this remains a not-well documented problem with too many uncertain fixes. Apple could help out by offering some clear guidelines as to what users should do.

Runaway process vs. insufficient memory

In replies to last week's article, several readers suggested that adding more RAM could help alleviate the symptoms. I agree. While I still don't view this as a generic memory matter (as the problem is linked only to a few specific processes), excessive disk activity is definitely a symptom of insufficient RAM.

A follow-up on App Store app bugs and iPhone/iTunes updates

On a completely different subject: If you haven't already done so, update to iTunes 8 and iPhone (or iPod touch) Software Update 2.1! These updates wipe out several app-related bugs, including ones noted in my recent article on messy App Store update tracking.

Gone are the various inconsistencies regarding the number updates available. Also gone are unneeded multiple copies of the same app in the Mac's Mobile Applications folder; older copies are now moved to the Trash when updating. The time needed to backup an iPhone with a large number of apps on it has also decreased significantly.

Finally, on your iPhone, Home screen icons for updated apps now remain in place, rather than moving to the end of the line. Thank you, Apple.

This story, "Bugs & Fixes: Dealing With CPU Overloads, Part Two" was originally published by Macworld.

Note: When you purchase something after clicking links in our articles, we may earn a small commission. Read our affiliate link policy for more details.
Shop Tech Products at Amazon