Don't want to disable indexing, just stop re-indexing

[sjonke]

The hints I've seen here give the advice of disabling spotlight indexing for the backup drive, but doing this means you can not search the backup drive at all! Finder and Spotlight return no results. Is there a way to just have Spotlight not re-index the drive after a smart update and use the existing index?

[dnanian]

No, I'm sorry -- not at present.

[sjk]

I can search volumes that Spotlight is disabled on, with different results from what they'd be when it's enabled since there's no content index. I've seen this error on a Spotlight-disabled volume:

% sudo mdutil -s /Volumes/Backup
/Volumes/Backup:
        Error, no index found for volume.

In my case, running Verify Disk with Disk Utility on that volume was enough to make it searchable again (with indexing off).

A potentially significant issue (IMO) with reindexing volumes is that certain metadata from original indexes will likely be lost. One example I'm aware of is the kMDItemWhereFroms attribute for files downloaded with Safari (and other apps?). Right now it's hard to know what the implications of this might be in different situations. Hopefully there will eventually be a "solution" for it. If nothing more, I'd like it to be clearer which metadata may be lost when reindexing so dependencies on it can be avoided.

[dnanian]

I brought this particular issue up numerous times in various sessions throughout WWDC, in the context of backing things up AND copying. Because, the fact is, these non-importer related metadata items are not backed up, and don't follow the file when copied.

So, it's hardly just reindexing. It's pretty much everything. Including backing up.

Spotlight has a lot of good things in it, but it doesn't have a lot of good data management issues for cases like this. (Fortunately, virtually everything in the database comes in through the importer -- everything but kMDItemWhereFrom -- and that is duplicated in the Spotlight comment, which *is* backed up.)

[sjk]

Originally Posted by dnanian

I brought this particular issue up numerous times in various sessions throughout WWDC, in the context of backing things up AND copying.

Your attention and interest about it is appreciated.

Because, the fact is, these non-importer related metadata items are not backed up, and don't follow the file when copied.

True.

So, it's hardly just reindexing. It's pretty much everything. Including backing up.

Yep.

Spotlight has a lot of good things in it, but it doesn't have a lot of good data management issues for cases like this.

Even with bugs and limitations I've made it useful.

(Fortunately, virtually everything in the database comes in through the importer -- everything but kMDItemWhereFrom -- and that is duplicated in the Spotlight comment, which *is* backed up.)

Hmm, I've never seen kMDItemWhereFroms duplicated to kMDItemFinderComment. In fact, I've been tinkering with the idea of automatically setting kMDItemFinderComment using the output of "mdls -name kMDItemWhereFroms file | cut -s -d '"' -f2 | head -n 1" since I lost the equivalent functionality by ditching the Saft plugin for Safari when upgrading to Tiger. Or maybe not, since I have on a slightly more ambitious project in mind.

I'm relieved if indeed only kMDItemWhereFroms is missing after copying or reindexing, assuming nothing's modifying other metadata. Some third party Spotlight+Automator project tagging stuff is using kMDItemFinderComment, which seems the only hook right now for users to "arbitrarily" extend Spotlight.

Thanks for the followup to this slightly off-topic topic. Hopefully it gets easier finding more accurate and detailed information about Spotlight as some of the misinformation hype settles down.