Since Spotlight Privacy behaves unpredictably when mounted/unmounted the FW volume it may work best to let SD! run the disable_spotlight script on it and avoid (re)indexing altogether.
But if a Spotlight index is copied from one volume and later restored to another volume using the same pathnames then would that avoid reindexing and preserve all the original metadata? If so, is there a scenario for running SD! so it stops/starts volume indexing at the right times and avoid reindexing that would occur because of pathname changes?
Quote:
|
... and it's unlikely that preserving metadata will resolve any kind of issues with kMDItemWhereFrom, because the paths change, so the metadata gets rebuilt anyway...
|
Aren't kMDItemWhereFroms (it's implemented as plural but not documented that way
) attributes just strings that won't be evaluated in a way that triggers reindexing except when that particular attribute changes (e.g. overwriting a file downloaded from a different location)?
Maybe an answer to my earlier question about a SD! scenario for Spotlight index preservation would be to remove the "-E" option from the disable_spotlight script so that the index won't be erased after it's copied to the backup volume and indexing will remain disabled. Later, if the backup volume (including the copied index) is restored to a volume with the same name as the original and indexing is reenabled afterwards would that be an effective way to preserve
all the Spotlight metadata, even "special" attributes like kMDItemWhereFroms that would otherwise be lost by rebuilding the index? Or would something else be changed in that backup/restore process to trigger a "massively destructive" index rebuild, similar what happens now after it loses the Privacy info for a volume even though there's a complete copied index on it?
Oh, that scenario assumes "Exclude Spotlight search index" from the copy script so the contents of /.Spotlight-V100
do get copied. Actually that's what my script for the startup volume already does since it excludes /Users (which is on a separate volume) and I haven't changed it since before 2.0 was released. Some scripts are overdue for attention; the include/exclude directives probably need adjustment.
Is there any sanity in my proposal for attempting to preserve metadata across backups/restores or would it probably become an exercise in futility because of still-quirky Spotlight behavior?