Spotlight indexes every drive I attach to my computer

Hi. Every time I attach an external HD or USB flash drive, Spotlight decides to start indexing it. I guess this can be a good feature in some cases, but when I attach my friends 300GB external HD which is completely full, it takes more than half an hour to do the indexing, which means that I basically can't use the drive for this whole time because Spotlight is using the drive at its full capabilities. Does anyone know of a way to turn off this automatic feature of Spotlight? Also, where does Spotlight's index file get stored: my internal HD or the HD/flash drive that the index file is for?
-Eric

Go to System Preferences / Spotlight / Privacy. Drag the icon for your newly mounted external hard drive from the Desktop into the Privacy list. Click on Show All to exit the Spotlight preferences pane or just exit System Preferences.
Spotlight will stop indexing that drive and discard whatever indexing it had already produced for that drive. If you mount that drive frequently, you can just leave it in the Privacy list if you'd like. If this is a one time thing, then after Ejecting and disconnecting that drive you can select that line in the Privacy list and delete it by clicking on the "-" at the bottom of the list.
--Bob

Similar Messages

Spotlight Indexing External Drives

I have been waiting about a week for Spotlight to Index my external drives, but the magnifying glass continually only shows "Estimating indexing time..." for each drive and never seems to go any further.
Any clues?
Thanks.
-Aaron

Aaron Welch wrote:
I have been waiting about a week for Spotlight to Index my external drives, but the magnifying glass continually only shows "Estimating indexing time..." for each drive and never seems to go any further.
It clearly doesn't like something on one of them. I'd start by excluding all of them from indexing, via System Preferences > Spotlight > Privacy, then running +*Repair Disk+* (not permissions) on each one, via Disk Utility, in your Applications/Utilities folder.
Then remove the exclusions, one at a time. If one hangs like that again, you'll at least know which one it is, and can try a process of elimination by excluding folders on that drive.

Confirmation on How to Stop Spotlight Indexing an External Hard Drive

Hello everyone,
I know there are a number of posts on this but I just want to confirm: Can I stop Spotlight from indexing my external FireWire hard drive by adding its name to the Privacy pane in Spotlight's preferences when the drive is mounted? (I'm a little low on internal hard disk space on my iBook so I want to keep the index as lean as possible.)

Georgy
Keep in mind that the index is stored on the drive that is being indexed. As such, indexing an external volume does not affect your main drive.
Remember also, that when you do update your external drive, the indexing only updates the changes made to the drive on the fly, provided of course if it is mounted and allowed to do so.
My suggestion, let Spotlight index the drive. Particularly if you are using it as a backup. Once in place, updating the index and searching is extremely fast.
Be careful however, of using third-party solutions. Some will affect Spotlight's normal indexing process and their preferences have to be changed for Spotlight to work.

Spotlight index unreliable on removable volumes

I have a removable drive that I want to index with Spotlight. As long as the drive is connected, Spotlight indexes the drive correctly.
If I unmounted the drive, disconnected it, and reconnected it, Spotlight will not "see" the index in that volume any more--none of the hits in that volume will be returned by the Spotlight search.
AFAIK the hidden Spotlight folders (.DS_Store and .Spotlight-V100) still exist on the volume. It's just that Spotlight does not reintegrate the index into its master index.
I can fix the problem by either going to System Preferences, and adding the volume to the Privacy list, then removing it; or by using the CLI command sudo mdutil -i off /Volumes/Name followed by sudo mdutil -i on /Volumes/Name (which does the same thing).
Is this a known bug? Is there a workaround?

Dave Rahardja wrote:
I have a removable drive that I want to index with Spotlight. As long as the drive is connected, Spotlight indexes the drive correctly.
If I unmounted the drive, disconnected it, and reconnected it, Spotlight will not "see" the index in that volume any more--none of the hits in that volume will be returned by the Spotlight search.
AFAIK the hidden Spotlight folders (.DS_Store and .Spotlight-V100) still exist on the volume. It's just that Spotlight does not reintegrate the index into its master index.
I can fix the problem by either going to System Preferences, and adding the volume to the Privacy list, then removing it; or by using the CLI command sudo mdutil -i off /Volumes/Name followed by sudo mdutil -i on /Volumes/Name (which does the same thing).
Is this a known bug? Is there a workaround?
That could be a bug. You might file a bug report with Apple about it. If others have same issue they will let you know.
File here:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/wa/signIn
If you reconnect the external drive and then reboot, does Spotlight pick it back up?
If so, what happens if you simply reconnect the drive and logoff and back on?
Spotlight is supposed to automatically access any attached drive not in the exclude list.

Continued Spotlight Indexing Problems

I'm still having problems with Spotlight indexing my drives into infinity. I just had a new 320g drive installed on my machine and, as I've posted before, Spotlight went ballistic trying to index it, telling me it had "2147483648 hours remaining" to complete indexing. As before, Activity Monitor shows mds taking over the system, hogging nearly 100% of the processor and causing the fan on my MacBook to go into overdrive.
As before, the only solution seems to be to shut Spotlight down completely. Using Spotless caused a freeze at first, and I had to reboot it and try again.
Does anybody know why this problem is so persistent? I've also noticed that Spotlight does not seem to search inside System Libraries any longer. Can anyone else verify this?

I'm having the same problem as well. I got a tool called Spotless. Which wasn't much help. I even deleted the index completely, restarted it and it still indexed ad infinitum. I think there's a problem with certain filenames or filetypes where it just chokes. Instead of crashing or erroring, it just stalls and keeps going. I'm trying to index my disks one at a time. But my system disk is the problem I think.

Is the spotlight index stored on the boot drive or individual volumes?

Hello!
My questions are pretty simple, and are sumarized here (from the block of text below):
First, if I have several external hard drives, is the Spotlight index file for each drive stored on the external hard drive, or on OS X's boot drive?
Secondly, if it's stored on the boot drive, can I copy these files to another Tiger-running Mac to eliminate the need to re-index the hard drives? Where do I find them?
Third: Leopard's Spotlight has quite a few new features. Even if the Tiger index files are stored on the external drive, will it need to re-index the drive to support the new feature set?
Now for the long explenation:
I have been preparing to upgrade my Powerbook to Leopard within the next month or two, and as such, I bought a new hard drive to dedicate one of my old drives to Leopard and Time Machine. Because I have three extrernal hard drives, I needed to move about 500 GB of data between the thee drives to make room for what was on the now-dedicated drive. Of course, this requires that Spotlight re-index the "new" drives.
Today, I left all of the drives attached to my old G4, running Tiger, while it sits there indexing the three drives, totaling around a terrabyte of external storage. Because Spotlight tends to hog all of the available CPU time, and the G4 should be done indexing the drives, it would save me a lot of time if I could copy the index files over from the G4 to my Powerbook to avoid indexing them all over again. That is, if the index files are not on the external drives already. If they are on the G4's boot drive, where do I find these files?
Finally, I plan to reformat the internal hard drive of my Powerbook when I install Leopard - I make a habit of doing a fresh install for every major upgrade (eg, 10.3, 10.4, 10.5, etc). To estimate the amount of time needed to upgrade, I'd be nice to know if Leopard will need to re-index the files on the external drives - even if Tiger's spotlight index is stored on the externals - for Leopard's new Spotlight features. Will it need to re-index? I would assume that until Leopard arrives, most people wouldn't know this, of course.
Thanks a bunch,
-Dan

Each drive's Spotlight index is located on that drive.
(25154)

How can I stop Spotlight from indexing external drives?

I work in an environment where we plugin several different costumer harddrives all day long as part of our working process. Often only to extract one file from a given drive. Therefore its annoying that Spotlight automatically starts indexing these drives, because it slows down everthing, but also because our windows costumers suddenly see these weird mac files on their drives, that are invisible to the macuser. The Privacy setting is not of much use, as its impossible to add oru costumers drives to the list - we simply don't know the drive until we see it.
How can spotlight stop indexing?

The Privacy option is okay for private users, but at work we receive alot of harddrives from costumers and we simply cannot spend the extra time waiting for a drive to be indexed every time it is connected. That drive may never be connected again as it belongs to a costumer, and it is impossible for us to add drives to the Privacy pane, because we do not know they exist before we see them infront of us. The ption to disable all external drives from being indexed would be great. Or that the indexing can be stopped in the spotlight menu, or that the indexing will not start until 10 minutes after the drive has been mounted - and only if the drive is inactive.

Stop Spotlight from indexing new drives

I know how to block a drive in Spotlight's privacy settings.
What I'm looking for is a way to stop Spotlight from indexing a drive every time I plug one in. I'm often connecting external drives for work & spotlight immediatley starts to index & I go in and add it to the blocked list in Spotlight> Privacy.
Is there a way to just have Spotlight NOT try to index a new drive?

Sorry, I missed that part.
Try this, add this file to the external drive.
touch /Volumes/name of the external drive/.metadata_never_index
This will add a file called .metadata_never_index to the root of that drive.
You can also disable spotlight
sudo mdutil -a -i off
To re-enable Spotlight:
sudo mdutil -a -i on

Lost the ability to Spotlight Index my Time Machine drive

I have an external, Firewire Time Machine drive which has been working without problems up to now. This evening I had a backup which hung up in the "preparing" stage (no file transfers begun yet). When I went to look in the console, there was a device error apparently related to trying to detect the powered-on state of my Time Machine drive. Apparently Time Machine did not handle this gracefully. In the course of trying to clear that I got into a state where I had to force shutdown of the system (holding the power button). (I accidentally clicked on the Time Machine icon which got hung up trying to display the histories, and left me with no access to the Desktop....)
Things appeared to check out fine when I brought the machine back up (including Verify Disk of both the main and Time Machine drives and Repair Permissions of the main drive), and I finally did a Back Up Now in Time Machine. Due to the forced shut down, this became a "Deep Traversal" "preparing"stage. We'll I've seen those before, so no worries. However it lasted quite a bit longer than it should, at which point I noticed that Spotlight was indexing the Time Machine drive.
So at this point I dragged the Time Machine into the Spotlight Privacy list. Rather than going away completely as I expected, the indexing of the Time Machine drive apparently went into some sort of clean-up phase that said it was still indexing for another 5 minutes (where it had, just prior, said it was going to be indexing for another 2 hours). The progress bar advanced normally as if it really did do 5 minutes more of indexing of the Time Machine drive. I've not seen this before
When that finished, the backup which had been "preparing" during all of this also finished "preparing", transferred the several MB of files I expected, and finished normally. There were no errors in the console related to any of this.
I rebooted, and once again did a pair of Disk Verifies and a Repair Permissions without problems. Opened up the console to track things, and poked around in the Time Machine. All was normal as far as I can tell. I also explored the Time Machine drive via the Finder. No problems.
So I now went into Spotlight Privacy and removed the Time Machine drive from the privacy list expecting it to do the re-indexing I had stopped above. Spotlight started indexing the drive and a couple seconds later it stopped. I tried again -- into and out of privacy -- same result, a couple seconds of indexing and then it stopped.
At this point I noticed the console was saying I had some bus errors in the I/O system, and that's what was terminating the md worker process and stopping the indexing.
So I shut down, unplugged the Time Machine drive, and went through my maintenance ritual.
I reset the PMU (this is a powerbook), reset PRAM, booted once in Safe Mode, booted normally, and ran Disk Utility again to Verify and Repair Permissions on the main hard drive. All of that went without a hitch. No failures, faults or funnies.
I ran through the list of Applications I use, keeping an eye on the console. Again no problems.
So I shut down, plugged the Time Machine drive back in and booted back up. I put the drive into Spotlight Privacy and turned off Time Machine backups. I then did a Verify Disk on that drive. No problems. I went into the Time Machine history display. No problems. And no problems looking at it in the Finder either. In particular, no bus errors or anything else funny in the console.
I rebooted and did a new Back Up Now. It completed without problems. It was another Deep Traversal backup due to the Safe Mode Boot, but it went without a hitch. I rebooted and did another Back Up Now and got a normal speed incremental backup again without a hitch. The bottom line is that as far as I can see that Time Machine drive is working just fine.
So I went into Spotlight Privacy and removed it from the list. Once again it started to index and stopped in a couple seconds. But this time there were NO Console error messages.
I moved my main hard drive into Spotlight Privacy and removed it and it re-indexed from scratch just fine. Tried again with the Time Machine drive -- indexing stopped in a couple of seconds with no message in the Console. Spotlight searches find all the right stuff in the main drive. Spotlight and finder searches find only the top level Time Machine folders in the Time Machine drive.
I also tried removing the Spotlight plist from my account's Library / Preferences. Spotlight created a new plist as expected but it still won't index that darned Time Machine drive.
Apparently there is something left over from when I originally aborted the Spotlight indexing of that drive which is causing Spotlight to think it has no work to do. I'm not seeing any I/O errors of any sort any more (I think my maintenance pass took care of that) and Time Machine backups and history access continue to work just fine. And again, the Time Machine disk Verifies just fine.
So I've run out of things to try.
Is there a hidden file that I need to remove from that drive so that Spotlight no longer thinks it already has it indexed?
--Bob

Well unfortunately the command
sudo mdutil -E /Volumes/MyDiskName
didn't help.
The command itself echoed the name of the volume and then said "Indexing Enabled", which looked good. But the Spotlight indexing stopped after a couple seconds. The Console reported the Terminal sudo command and nothing else.
I tried moving the Time Machine drive in and out of Spotlight privacy and once again the indexing started and stopped a couple seconds later with no Console messages.
I then tried another trick I've learned to make Spotlight indexing happen which is to do a Finder search for, say, all folders (limited to the one drive) via Command-f and while Including both System Files and files both Visible and Invisible. And indeed Spotlight indexing started but again stopped a few seconds later.
However, this time there were console messages and a crash report.
The Console shows (with personal information x'ed out):
12/31/07 1:30:38 PM mds[28] (/)(Error) IndexCI in openindex_filelazy:open file error: 2, 0.indexGroups
12/31/07 1:30:41 PM ReportCrash[146] Formulating crash report for process mds[28]
12/31/07 1:30:42 PM com.apple.launchd[1] (com.apple.metadata.mds[28]) Exited abnormally: Bus error
12/31/07 1:30:42 PM com.apple.launchd[1] (0x10ba40.mdworker[96]) Exited: Terminated
12/31/07 1:30:42 PM com.apple.launchd[1] (0x1004a0.mdworker[108]) Exited: Terminated
12/31/07 1:30:42 PM mds[147] (/Volumes/Xxxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/80F3EC85-D77A-49FE-8BDC-BB7C3B3EC1CF)(E rror) IndexCI in ContentIndexOpenBulk:Unclean shutdown of /Volumes/Xxxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/80F3EC85-D77A-49FE-8BDC-BB7C3B3EC1CF/0. ; needs recovery
12/31/07 1:30:43 PM ReportCrash[146] Saved crashreport to /Library/Logs/CrashReporter/mds2007-12-31-133038Xxxxxx-Xxxxxx-Computer.crash using uid: 0 gid: 0, euid: 0 egid: 0
The Crash Report reads as follows (again with personal information x'ed out):
Process: mds [28]
Path: /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework /Support/mds
Identifier: mds
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: launchd [1]
Date/Time: 2007-12-31 13:30:38.746 -0500
OS Version: Mac OS X 10.5.1 (9B18)
Report Version: 6
Exception Type: EXCBADACCESS (SIGBUS)
Exception Codes: KERNPROTECTIONFAILURE at 0x0000000000000030
Crashed Thread: 15
Thread 0:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0000cfa0 0x1000 + 49056
5 mds 0x00005580 0x1000 + 17792
Thread 1:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 2:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 3:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 4:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 5:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 6:
0 libSystem.B.dylib 0x92eda3ec _semwaitsignal + 12
1 libSystem.B.dylib 0x92f16fa0 pthread_condwait + 1580
2 mds 0x00009648 0x1000 + 34376
3 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 7:
0 libSystem.B.dylib 0x92ee0ea0 read$UNIX2003 + 12
1 mds 0x000091b4 0x1000 + 33204
Thread 8:
0 libSystem.B.dylib 0x92f15438 kevent + 12
1 mds 0x0007e584 0x1000 + 513412
Thread 9:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 10:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 11:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 12:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 13:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.spotlight.index 0x00207f0c _handleExceptions + 208
3 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 14:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 15 Crashed:
0 com.apple.spotlight.index 0x002046cc ContentIndexContainsContentByDocId + 204
1 com.apple.spotlight.index 0x00164358 QueryFunctionCallbackContext::findContent(db_obj*, __CFString const*, char*, int) + 244
2 com.apple.spotlight.index 0x001634d0 qpContentIndexMatch(datastoreinfo*, dblazyobj*, query_piece*, void*, int) + 328
3 com.apple.spotlight.index 0x0015587c comparefile_againsttree + 828
4 com.apple.spotlight.index 0x00155d30 comparefile_againsttree + 2032
5 com.apple.spotlight.index 0x00155d5c comparefile_againsttree + 2076
6 com.apple.spotlight.index 0x001e307c -[SISearchCtx isObjectInQuery:withQuery:shortcut:] + 144
7 com.apple.spotlight.index 0x001fa268 -[SISearchCtx_FSWalk performSearch:] + 996
8 com.apple.spotlight.index 0x001e2cbc -[SISearchCtx executeSearchContextCracked_2:jobNum:] + 136
9 com.apple.spotlight.index 0x00177e80 siwork_queueprocess + 752
10 com.apple.spotlight.index 0x0017811c sischeduleronce + 356
11 com.apple.spotlight.index 0x0017816c sischeduleronce + 436
12 com.apple.spotlight.index 0x001784f8 sischeduler_run_waitingtimeout + 640
13 com.apple.spotlight.index 0x0016529c runLoop + 72
14 com.apple.spotlight.index 0x00165308 query_runLoop + 32
15 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 15 crashed with PPC Thread State 32:
srr0: 0x002046cc srr1: 0x0200f030 dar: 0x00000030 dsisr: 0x40000000
r0: 0x002046a4 r1: 0xf09a4380 r2: 0x00000000 r3: 0x00000000
r4: 0xf09a43c0 r5: 0x00000000 r6: 0x000074d1 r7: 0x00000000
r8: 0x003fc080 r9: 0x00000000 r10: 0x00000000 r11: 0x44000444
r12: 0x92ede094 r13: 0x00000000 r14: 0x00000000 r15: 0x00373410
r16: 0x00000000 r17: 0x00239e98 r18: 0x00000001 r19: 0x00227b9c
r20: 0x00000000 r21: 0x00245554 r22: 0x00000001 r23: 0x00000001
r24: 0x00000000 r25: 0x00000005 r26: 0x00000000 r27: 0x00000000
r28: 0x00000000 r29: 0x00000005 r30: 0xf09a43c0 r31: 0x00204610
cr: 0x24000444 xer: 0x20000004 lr: 0x002046a4 ctr: 0x92ede094
vrsave: 0x00000000
Binary Images:
0x1000 - 0xc1ffb mds ??? (???) <af9cc958b4b030835101ff024186c7d3> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework /Support/mds
0xde000 - 0xe0ffd com.apple.MDSChannel 1.0 (1.0) /System/Library/PrivateFrameworks/MDSChannel.framework/Versions/A/MDSChannel
0x139000 - 0x23fffb com.apple.spotlight.index 10.5.0 (398.1) <5843125c709dd85f22f9bd42744beea5> /System/Library/PrivateFrameworks/SpotlightIndex.framework/Versions/A/Spotlight Index
0x1ca9000 - 0x1caaffc liblangid.dylib ??? (???) <5f078ac1f623f5ce432ea53fc29338c0> /usr/lib/liblangid.dylib
0x2198000 - 0x22bdffb libmecab.1.0.0.dylib ??? (???) <cd875e74974e4ec3a0b13eeeb236fa53> /usr/lib/libmecab.1.0.0.dylib
0x8fe00000 - 0x8fe309d3 dyld 95.3 (???) <a7be977c203ec5c76b2f25a7aef66554> /usr/lib/dyld
0x90123000 - 0x9016effb com.apple.Metadata 10.5.0 (398) <b6bb1fd5a7a9135f546b2d8cbd65eafc> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadat a.framework/Versions/A/Metadata
0x901ab000 - 0x902d0ff3 com.apple.CoreFoundation 6.5 (476) <9073c2bfdf6842562c8b7f0308109c02> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9060a000 - 0x90612fff libbsm.dylib ??? (???) <c1fca3cbe3b1c21e9b31bc89b920f34c> /usr/lib/libbsm.dylib
0x90683000 - 0x90688ff6 libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0x90757000 - 0x907d2fff com.apple.SearchKit 1.2.0 (1.2.0) <1b448fbae02460eae76ee1c6883f45d6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchK it.framework/Versions/A/SearchKit
0x9088a000 - 0x9090ffff libsqlite3.0.dylib ??? (???) <7b379cb4220346e99c32c427d4539496> /usr/lib/libsqlite3.0.dylib
0x90aa7000 - 0x90ab5fff libz.1.dylib ??? (???) <1a70dd3594a8c5ad39d785af5da23237> /usr/lib/libz.1.dylib
0x90b50000 - 0x90be2fff com.apple.framework.IOKit 1.5.1 (???) <591b8b0cc4261db98a6e72e38eef5f9a> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x91105000 - 0x9116cffb libstdc++.6.dylib ??? (???) <a4e9b10268b3ffac26d0296499b24e8e> /usr/lib/libstdc++.6.dylib
0x9116d000 - 0x912b5ff3 libicucore.A.dylib ??? (???) <250daed2fb2e6bf114480e2e4da0728b> /usr/lib/libicucore.A.dylib
0x91c3c000 - 0x91d32ffc libiconv.2.dylib ??? (???) <05ae1fcc97404173b2f9caef8f8be797> /usr/lib/libiconv.2.dylib
0x91d3a000 - 0x91db4ffd com.apple.CFNetwork 220 (221) <00b882d3d3325526b78ded74880759fe> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwo rk.framework/Versions/A/CFNetwork
0x9236a000 - 0x92382ffb com.apple.DictionaryServices 1.0.0 (1.0.0) <fe37191e732eeb66189185cd000a210b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Diction aryServices.framework/Versions/A/DictionaryServices
0x92383000 - 0x9238effb libgcc_s.1.dylib ??? (???) <ea47fd375407f162c76d14d64ba246cd> /usr/lib/libgcc_s.1.dylib
0x92742000 - 0x92769fff libxslt.1.dylib ??? (???) <3700d04090629deddb436aa2d516c56d> /usr/lib/libxslt.1.dylib
0x92777000 - 0x92860fff libxml2.2.dylib ??? (???) <6f383df1e1e775be0158ba947784ae13> /usr/lib/libxml2.2.dylib
0x928aa000 - 0x928b9fff com.apple.DSObjCWrappers.Framework 1.2 (1.2) <2411674c821a8907449ac741ce6a40c3> /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWra ppers
0x92a17000 - 0x92afafeb libobjc.A.dylib ??? (???) <4a90e315bd1718c3f5ae09ee6c23e36c> /usr/lib/libobjc.A.dylib
0x92afb000 - 0x92bc9ff7 com.apple.CoreServices.OSServices 210.2 (210.2) <bad4943629f870d305f2bc7c6dfffe2d> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServi ces.framework/Versions/A/OSServices
0x92bde000 - 0x92dbfffb com.apple.security 5.0.1 (32736) <15632bf9bbdb223194b3d79a2e48e02d> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x92e9a000 - 0x92ec5ff7 libauto.dylib ??? (???) <c1f2bd227817ad7c7bf29ec74729ac7c> /usr/lib/libauto.dylib
0x92ed2000 - 0x9306bfe3 libSystem.B.dylib ??? (???) <8a6cd873dfa7ada786efac188f95ed1b> /usr/lib/libSystem.B.dylib
0x931a7000 - 0x934a7ff3 com.apple.CoreServices.CarbonCore 783 (783) <fd2acaf23e95472f78b8a077fa039986> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonC ore.framework/Versions/A/CarbonCore
0x946f2000 - 0x9472afff com.apple.SystemConfiguration 1.9.0 (1.9.0) <d925dde7699e6231c88a41b0254a7591> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfi guration
0x94933000 - 0x9494eff3 com.apple.DirectoryService.Framework 3.5 (3.5) <3246a5d1c6a3d678798a90e8c5cd3677> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryServi ce
0x9494f000 - 0x9494fffa com.apple.CoreServices 32 (32) <42b6dda539f7411606187335d9eae0c5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x94c68000 - 0x94c9dfff com.apple.AE 402 (402) <a4b92c8ac89cc774b85fb44c48b9d882> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.fram ework/Versions/A/AE
0x96831000 - 0x9683afff com.apple.DiskArbitration 2.2 (2.2) <9c8f8ade43fa25b32109ef9dcc0cb5d5> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9683b000 - 0x968d1ff7 com.apple.LaunchServices 286 (286) <a3a0b2af862e9a8945072f8cb523678f> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchS ervices.framework/Versions/A/LaunchServices
0x969bc000 - 0x96c00ffb com.apple.Foundation 6.5.1 (677.1) <4152239382fb0f48abbcbf35bd04afa6> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0xfffec000 - 0xfffeffff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib
0xffff8000 - 0xffff9703 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Apparently the mdutil command didn't actually delete the Spotlight index file which is causing the problem, or at least didn't leave the indexing files in a consistent, empty state to start indexing over again. I may have to Erase this Time Machine disk and start over.
I should point out that except for Spotlight indexing this disk is otherwise working just fine. It passes Verify Disk with no errors and both new Time Machine backups and viewing and restoring via Time Machine and Finder work without problem.
Any suggestions before I just Erase the disk and start over with a new backup?
--Bob

Tried to fix spotlight indexing and lost my entire drive and backup; can you help me find them?

Hi,
I am in a complete crisis. If anyone can help me, I'd be very grateful.
I tried to correct my Spotlight indexing by using a combination of the sudo mdutil -E / , sudo mdutil -i on / , and sudo rm -rf /.Spotlight-V100 commands from the terminal.
I am not sure what happened, but the computer went into an interminable color-wheel and, when I shut down and rebooted after an hour or two, I found that both my main drive and my backup drive had severe problems.
DiskUtility volunteered to correct these. I ran it on my main drive and found that my entire directory appears to have been erased.
Disk Warrior cannot repair. Nor can TechTool. Both declare that the directory structure is now beyond repair (which they also say of my former backup clone).
My main drive now has barely nine files left - and a handful of empty folders:
file:///Volumes/Eric's HD/Library/Application Support/
file:///Volumes/Eric's HD/Library/Application Support/CrashReporter/
file:///Volumes/Eric's HD/Library/Keychains/System.keychain
file:///Volumes/Eric's HD/Library/Preferences/com.apple.TimeMachine.plist
file:///Volumes/Eric's HD/Users/ericcolvin/Library/Frameworks/
file:///Volumes/Eric's HD/Users/ericcolvin/Library/Preferences/com.apple.Terminal.plist
file:///Volumes/Eric's HD/Users/ericcolvin/Library/Preferences/com.bittorrent.uTorrent.plist
file:///Volumes/Eric's HD/Users/ericcolvin/Library/Preferences/com.apple.finder.plist
file:///Volumes/Eric's HD/Users/ericcolvin/Library/Autosave Information/
file:///Volumes/Eric's HD/System/Library/CoreServices/boot.efi
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.kext.caches/Startup/
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.kext.caches/Directories/System/
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.kext.caches/Directories/System/Library/Exten sions/KextPropertyValues_OSBundleHelper_i386.plist.gz
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.kext.caches/Directories/System/Library/Exten sions/KextIdentifiers.plist.gz
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.kext.caches/Directories/System/Library/Exten sions/IOKitPersonalities_i386.ioplist.gz
file:///Volumes/Eric's HD/System/Library/Caches/com.apple.bootstamps/0E6271FF-3F33-3661-9B4A-38AFF32D4 860/
file:///Volumes/Eric's HD/Applications/
file:///Volumes/Eric's HD/net/
file:///Volumes/Eric's HD/home/
Though I did not run any file repairs on the back up drive, it has also lost all of its files (it shows just one remaining
file:///Volumes/Eric's Backup/System/Library/CoreServices/boot.efi - whatever that is).
FileSalvage is now beavering away, attempting to scavenge some 350Gb of applications, e-mails, photos, iTunes, and movies (most of which it is unable to name). But these will all be unlabelled and randomly organised by extension type. These could take months to sift through and the list is almost certain to be incomplete. I have no other backups of my system apart from a two year old clone.
Please tell me. Is there anything I can do to get back my lost directory structure?
                       Might there be some use of an Undelete routine that might recover the directory alone and thus allow me to salvage either disk?
                        I don't even know what sort of extension to hunt for in order to attempt such a restore
                       - nor how I might drop it back into its correct spot on the volume.
All suggestions gratefully received.

Thanks, guys.
Yes, FileSalvage seems able to retrieve a vast jumble of unnamed "junk files," a tiny percentage of which are probably highly valuable to me. The problem will be finding them amongst the jumble. It could take weeks. ITunes files and MP3s are more promising, as it seems to have been able to reconstruct the files' names - and even cover art - from their metadata.
No. TechTool Pro wrote nothing at all. Sadly, though, I had allowed Disk Utility to reduce the number of threads or leaves or something in the volume directory, before I realised the gravity of the situation. It has thus made a very small alteration to my main drive (resulting, no doubt in the creation of those 9 system files and their containing folders). But the back-up drive had nothing further written to it since the apparent deletion of the volume.
I downloaded a freeware program called TestDisk which claims to analyse drive partitions. The partitions on each of my two physical drives (the internal and the backup clone) were not apparently affected - just the total loss of the volume directory structure on the boot partition in each case. So, would this be the wrong tool for the job? http://www.cgsecurity.org/wiki/TestDisk It does claim to be able to "Rebuild NTFS boot sector." I don't really know what that means. Can anyone tell me whether a rebuilt boot sector will enable me to recover a deleted volume directory structure?
Meanwhile, I am also running a trial version of Stellar Phoenix, which claims to reinstate "lost/deleted volumes." It claims to have "found 6 lost/deleted volumes" already - after five hours, during which it has scanned about 5% of my 1.5 T external drive. So I suppose it may well take days to finish scanning. Then, I expect it may ask me to buy a serial code in order to proceed.
Does anyone have experience with Phoenix, or understand the jargon about lost/deleted volumes? Once I've bought the full version, is there a good chance it will actually reconstruct the whole volume as it once was - or is it more likely just to scavenge scores of thousands of nameless file snippets as per FileSalvage?
I don't have a problem with paying the boffins at Stellar if they are actually able to save me months of sifting through random unnamed files in order to locate the ones I've lost.

How to stop Spotlight from indexing backup drives

Is there any way to stop Spotlight from indexing backup drives?
Thanks

Yes, in Spotlight preferences there is an option to do this. I'm not on my Mac now, so I forget exactly where in Spotlight preferences it is. I believe there is a second tab that you have to click on, then click the "+" sign to add items to Exclude. Just add your backup drive.

Spotlight indexing of Time Capsule - feature or bug?

I understand why backups are indexed: the ability to use Spotlight from within Time Machine is a fantastic feature. But the method by which this index is created does not make sense where a Time Capsule is in use (or indeed most networked storage, but since many configurations are officially unsupported let's just keep this discussion focused on the officially approved one!).
Typically (from my sample size of 1), a complete system backup is of the order of 100GB; however, after the initial backup is complete, Time Machine only needs to copy modified files to the backup drive, which can lead to very small and fast subsequent backups: unchanged files are created in-situ with a hardlink to the existing copy on the backup drive.
A problem arises when, after a backup completes, Spotlight attempts to index the changes to the backup drive: it appears that it inspects every unindexed file (involves transfer to the local machine) including such unmodified/hardlinked files. This therefore gives rise to a situation where a backup that writes only a few kilobytes to the backup drive results in Spotlight reading hundreds of gigabytes from that drive.
Even with a throughput of 100Mbps, this would take close to an hour and a half (in reality, especially over wireless networks, it takes many hours); meanwhile Time Machine reaches its next scheduled backup and cannot proceed until Spotlight has finished indexing.
Altogether, this appears to render Time Capsules useless for system backup (unless one is connected via gigabit ethernet, which is neither a requisite nor a desirable constraint). One does not need to look far to see how many users this issue is affecting.
In previous versions of OS X, one could workaround this issue by disabling Spotlight indexing of the backup volume; however, since Lion (or Snow Leopard?), this is no longer possible.
To my mind, the design is flawed - some might call it a "bug": there should be a more efficient method of indexing drives, especially networked ones (ideally avoiding the redundancy of reindexing hardlinked files). At worst, Time Machine could provide to Spotlight all the metadata it requires for the entire backup: thus avoiding the need for Spotlight to read such files from the backup volume.
...or have I misunderstood something?

nickety wrote:
I understand why backups are indexed: the ability to use Spotlight from within Time Machine is a fantastic feature.
That's not the reason; Time Machine requires the indexing in order to work, especially for the "Star Wars" display.
Altogether, this appears to render Time Capsules useless for system backup
That's not normal; you have something else wrong, possibly a corrupt index. See the pink box in #D2 of Time Machine - Troubleshooting.
In previous versions of OS X, one could workaround this issue by disabling Spotlight indexing of the backup volume
Not really. The backups were still indexed; you just didn't get a message. See the note in item 2 here: http://docs.info.apple.com/article.html?path=Mac/10.6/en/8991.html

Spotlight frequently reindexes drives in Snow Leopard

Spotlight frequently reindexes my drives (like every other day), taking between 7 and 20 hours each time and generally bogging down my system when I'm trying to get real work done.
The basic classes of error reported by mds, as seen in the system log using Console.app, are: that the index is corrupted or "Job appears to have crashed: Segmentation fault" which inevitably seems to lead to a total reindexing.
I routinely run disk utility on my external drives and fsck on the internal drive, booting in single-user mode and no disk problems are ever detected.
I've repeatedly tried deleting spotlight cache folders, and resetting the spotlight indexing via the OS X command line to force it to start anew. And this seems to work for perhaps an extra day or two, but it inevitably and quickly devolves to the same pattern. And a full reindexing even once a week, let alone several times a week, is totally absurd: a broken model for computer use.
Other items of note: the internal drive on this system currently has plenty of disk space (50GB free out of 250GB total).
Any suggestions?

which terminal command was that? please be specific.
try the following terminal commands (copy and paste, please)
sudo mdutil -i off /
sudo rm -rf /.Spotlight-V100
sudo mdutil -i on /
You'll have to enter your admin password (which you won't see) after the first command. that's normal.

Trying to disable spotlight on firewire drives...

I have tried throught the Terminal as well as privacy prefs to disable a couple backup firewire drives from indexing. However every time I restart spotlight tries to index again. It seems to forget the settings. Anyone with a similar experience that has a solution for me?
Thanks for the help.

Download a copy of Spotless. From the app. you can disable indexing for the drives (make sure they are on when doing so). Afterward, open your System Preference panel for Spotlight and add the drives or drives' partitions into the privacy pane. That ought to stop Spotlight from indexing the drives.

Isn't the Spotlight Index File a Massive Security Threat?

I'm wondering about the concept that Spotlight makes a really deep search -- and record -- of all user-created text files on your computer.
In order for Spotlight to know that a file called "My Personal Stuff.rtf" contains the words "bank", "account", "number", "1234-567890" it needs to copy each of those keywords into the Spotlight index. That means in effect that Spotlight is making a *complete copy* of *all words* in *all text documents* ever on or temporarily connected to your computer, except for un-searched words like "the", "and", etc.
If you've ever plugged your thumb drive into a public Mac somewhere, Spotlight got to work and copied all the (key-) words in every file on your thumb drive into the Spotlight index on that computer.
If you're happy that at least you had Filevault turned on when your laptop with the big corporate secrets and list of thousands of people's personal info got stolen -- there was also a non-Filevaulted Spotlight index on that computer with all the contents of every document extracted as keywords, for the sophisticated cyber criminals to pore over.
Of course, you can turn off Spotlight indexing -- if you never want to be able to find a file on your computer even by file name... on your own computer at least. Not on that other computer you're plugging your drive into.
Is there something I'm missing here?
I'm not the first to wonder this -- see this archived, and cluelessly unanswered and unconcluded -- post from last year:
http://discussions.apple.com/thread.jspa?threadID=1390619

glkdfhgkdfjghdfkgjhdfkgjh wrote:
I'm wondering about the concept that Spotlight makes a really deep search -- and record -- of all user-created text files on your computer.
In order for Spotlight to know that a file called "My Personal Stuff.rtf" contains the words "bank", "account", "number", "1234-567890" it needs to copy each of those keywords into the Spotlight index. That means in effect that Spotlight is making a *complete copy* of *all words* in *all text documents* ever on or temporarily connected to your computer, except for un-searched words like "the", "and", etc.
If you've ever plugged your thumb drive into a public Mac somewhere, Spotlight got to work and copied all the (key-) words in every file on your thumb drive into the Spotlight index on that computer.
If you're happy that at least you had Filevault turned on when your laptop with the big corporate secrets and list of thousands of people's personal info got stolen -- there was also a non-Filevaulted Spotlight index on that computer with all the contents of every document extracted as keywords, for the sophisticated cyber criminals to pore over.
Of course, you can turn off Spotlight indexing -- if you never want to be able to find a file on your computer even by file name... on your own computer at least. Not on that other computer you're plugging your drive into.
Is there something I'm missing here?
yes, you are. spotlight index for a drive is kept on that drive. it's not copied to any other drive. that also applies to virtual volumes contained in disk images like a filevaulted home directory. that is, spotlight index for a filevaulted home directry is stored inside the sparse bundle with that home directory. nobody else has access to it and when you are not logged into a filevaulted account there is no trace of the spotlight index for it on the system.
I'm not the first to wonder this -- see this archived, and cluelessly unanswered and unconcluded -- post from last year:
http://discussions.apple.com/thread.jspa?threadID=1390619
Message was edited by: V.K.

Spotlight indexes every drive I attach to my computer

Similar Messages

Maybe you are looking for