indexing won't stop. help?

rok

okay, so i decided that searching by content on my secondary drive was taking too long, so i thought i should force and index of it through the "get info" dialog.



it churned and chugged and then finished... HOWEVER, the get info. box status says "indexing..." with a progress bar that isn't doing anything. the "stop indexing" button is active, bt does nothin no matter how often i click it.



the "indexing..." stays on EVEN THRU A RESTART. wtf?!?



i might think this is just a problem with the window updating, but when i try to do a search by content on that drive, the finder crashes and relaunches.



so, what the hell is going on, or, better yet, how can i stop this?



any help would be greatly appreciated.

rok

well, i think i foudn the answer, on the macfixit forums (i usually don't find anything useful there anymore, but thankfully someone had already done the troubleshooting and analysis).



Summary



The current version of ContentIndexing seems to have a serious bug. Apparently, it is not possible to index folders that enclose previously-indexed folders when the cumulative number of enclosed files exceeds 20,000. Furthermore, some preexisting indexes are deleted when find-by-content is first performed on a folder that encloses them and the search operation seems to enter an endless loop. This will sooner or later occur in any disk where searches are effected on a hierarchy of folders.



Symptoms



Using Get Info's Content Index function, one can successfully index any folder containing any number of files. For each indexed folder, the indexing function creates an invisible file called .FBCIndex and places it inside each folder. Searching by content on each of these separately-indexed folder behaves normally.



But if an attempt is made to index an enclosing folder that contains at least one previously-indexed folder and over 20,000 files, its Get Info window indicates the total number of files to be indexed as being exactly 20,000, which is an error, as it should report a much higher number.



After letting this second indexing complete on the 20,000 reported files, the Get Info window shows an "Indexing..." message, together with an unresponsive "Stop indexing" button. (This behavior has been reported by several users, both here as well as in Apple forums.) The bogus "Indexing..." message persists, stuck in a continuous loop that survives restarts.



However, no indexing is being done. When an actual indexing operation is carried out, Process Viewer shows the ContentIndexing process being executed. This is not the case for the bogus "Indexing..." message.



Ensuing behavior



Once the bogus "Indexing..." message has appeared, several things happen:



1) The data in the pre-existing indexes of some enclosed folders will propagate upwards (towards the enclosing folder) and create an aggregate index, as their .FBCIndex files are renamed to .FBCIndexCopy. This is not done for every folder: some .FBCIndex files remain unchanged, consistent with the self-imposed 20,000 file limit for the propagated indexes. The new aggregated index only includes information for the first 20,000 files and discards the rest of the data.



2) Searching by content in the enclosed folders will now fail for the excess of 20,000 files.



3) A find-by-content on the enclosing folder will enter what seems to be an endless loop, although it may work on files within folders whose indexes have not been propagated upwards into the 20,000-file aggregate index.



4) Additional .FBCIndex files spontaneously appear inside folders that were not separately indexed.



5) Several .FBCIndexTemp files are created. Considering their names, they should be automatically deleted at some point in time.



Solution



A general solution is detailed below:



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's

sudo find / -name ".FBC*" -delete -print

sudo find / -name FBCPrivateIndexDB.plist -print -delete



(edited from original, to prevent someone from, say, accidentally erasing their hard drive)



3) Delete the invisible file FBCPrivateIndexDB.plist.



4) Restart the computer.



5) Re-index only the top-level folders, such as /Documents and /Users/<username>. (The ContentIndexing process will create separate indexes for large folders, in top-down fashion.)



In this way, you close the door to any "übersearches" so that no indexes can become corrupt by being included in a higher-level search-by-content operation. Most top-level folders in your disk cannot be indexed, but it will still be possible to search within those folders that do allow indexing.



Leave Get Info's Indexing running overnight, as it is a low-priority task and has a tendency to yield to other processes and quit. Besides, a search-by-content operation will not terminate unless the folder has been flagged as fully indexed.



And from then on, never re-index with Get Info anything but the topmost folders. That is, until this problem gets fixed.



p.s. this bug, as i have just discovered, is not fixed as of 10.2.8

jwri004

Have you "killed" the process via terminal?



Code is:



top



Find the process number - should be called ContInd (or something similar). Press q to stop top.



sudo kill insert process number here



Should ask you for your admin password

rok

Quote:

Originally posted by jwri004

Have you "killed" the process via terminal?



Code is:



top



Find the process number - should be called ContInd (or something similar). Press q to stop top.



sudo kill insert process number here



Should ask you for your admin password

yep. i killed it with process viewer first. then went thru terminal and got rid of all those FBC files.



this was triggered after using softhing.com's Entourage Email Archiver on my healthy Entourage database, and then indexing the drive so i could search by content. that triggered the bug (as i had well over 20,000 files).



basically, if you have a lot of files and folders on a drive, do NOT just index the volume. it'll never stop, and will crash any attempt to search by content.