Troubleshooting Mac OS X 10.2.x: Content indexing problems

MacFixIt reader Rock Norris has spent some time researching a problem with the "find by content" functionality in Mac OS X that crops up when it is presented with too many files:

"First of all, as you know, you can search "by content" through the Mac OS' default 'Find...' feature (formerly part of the application Sherlock, also by Apple). However, searching by content through a lot of files can take forever, unless you allow the computer to index your files during down times, such as overnight. It then compiles invisible lists of unique terms in document summaries, which it then places on your hard drive and uses whenever you "search by content..."

"Well, I decided that searching for an item through my email archives was taking far too long (I use Entourage Email Archiver, which creates time/date stamped folders and plain text files of all your email, rather than relying on Entourage's database), so I thought I should force an index of the drive containing all of my archived emails.

"All was fine until... It churned and chugged and then finished...or so I thought. However, the get info. box status says "Indexing..." with a progress bar that doesn't do anything. Clicking the "Stop indexing" button does nothing. What was really bizarre was that this behavior continues even through a restart. While I first thought this might only be cosmetic, any attempt at searching by content on that drive results in a finder crash, and relaunch, or other random error.

"This is a repeatable bug under OS X (all versions so far), if an index is attempted on a drive that contains an excessive number of files/folders (the magic number seems to be the neighborhood of 20,000). Under Mac OS 9 and smaller drives, this wasn't an issue. Now under Mac OS X and larger drives such as 60, 80 or 100+ GB, it is an issue.

"Basically, as the Mac OS attempts to create these invisible content databases, it will start spawning them recursively, too (in other words, an index OF another index OF another index, and so on...). If you open process viewer, you will see ContentIndexing taking usually 50% or more CPU usage during this. You can kill that individual process, but invoking the "find..." command on a folder starts indexing back up for whatever drives or folders you are looking through. So it never stops. And remember, it survives repeated restarts, too. So if you are noticing significant slowdowns in your computer operation, open up Process Viewer in your Utilities folder, and see if you find a 'ContentIndexing' process chewing up processor time and power. And this may have been started many restarts ago."

Another MacFixIt reader, posting to the forums, provided this workaround. Note that this will break the find by content functionality as a whole, but will also stop the CPU eating process from running in the background and let you index specific areas on your drive:

1. Stop ContentIndexing using Process Viewer. Otherwise, find-by-content indexes will regenerate even as you delete the following files.

2. Delete all invisible files named .FBCIndex, .FBCIndexCopy, .FBCSemaphoreFile and all invisible folders named .FBCLockFolder using Terminal and the following commands (you will need to enter your password at least once, and the terminal will appear to not be doing anything while it looks for the files, but let it do its job... It will eventually find them, list them as it deletes them, and end once it has found all of the offending files and give you back the prompt when it is complete).

• sudo find / -name ".FBC*" -delete -print (wait until finished)
• sudo find / -name FBCPrivateIndexDB.plist -print -delete

3) Restart the computer.

4) Re-index only particular folders with limited number of subfolders, and make sure to move your files off your drives to backup media on a regular basis to avoid the "too many files and/or folders to index" bug.

Feedback? Late-breakers@macfixit.com.

Resources