OpenMetaSpotlight.mdimporter v.3.0 breaks existing Smart Folders

42 views
Skip to first unread message

Jon Stovell (a.k.a. Sesquipedalian)

unread,
Nov 2, 2009, 9:58:55 PM11/2/09
to OpenMeta
Version 3.0 of the OpenMetaSpotlight.mdimporter implements the change
from kOMUserTags to kMDItemOMUserTags in the schema.strings file. This
breaks Smart Folders that search for tags and which were created using
earlier versions of the mdimporter. These older Smart Folders use the
kOMUserTags key in their .savedsearch files, and thus fail to work
with v. 3.0 of the mdimporter, which specifies kMDItemOMUserTags
instead.

In specific, versions of the mdimporter prior to v. 3.0 included the
following in schema.strings:

"kOMUserTags" = "Tags";

As a result, Smart Folders made with "Tags" criteria would include the
following in their FXCriteriaSlices key of their SearchCriteria key:

<array>
<dict>
<key>criteria</key>
<array>
<string>kOMUserTags</string>
<integer>120</integer>
<integer>104</integer>
</array>
<key>displayValues</key>
<array>
<string>Tags</string>
<string>matches</string>
<string>foo</string>
</array>
<key>rowType</key>
<integer>0</integer>
<key>subrows</key>
<array/>
</dict>
</array>

By changing the schema.strings values to read:

"kMDItemOMUserTags" = "Tags";

version 3.0 of the mdimporter causes all of these Smart Folders to die
a horrible death, complete with graphical glitches in the Finder
window if the user tries to manually edit the search criteria of the
broken Smart Folder.

While I appreciate the need to address the problem with Snow Leopard
overwriting extended attributes, introducing a change that renders a
user's previously saved searches inoperable—and thereby renders my
software, Tag Folders, inoperable—is not acceptable.

Moreover, even if I were to implement a method to rewrite all of the
Smart Folders created by my software (and leave the user to fend for
themselves with their own broken Smart Folders), I would not be able
to avoid problems. Because there are multiple, incompatible versions
of the mdimporter floating around inside various application bundles
that the user may have installed, and only one of them will be used by
Spotlight at a time, it is not an easy task to determine whether a
user's system currently thinks that "Tags" in the Spotlight search
criteria means kOMUserTags or kMDItemOMUserTags. This means that I
can't reliably choose one or the other key.

Something must be done to address this, not only for my software to
keep working, but so that users don't suddenly find that their Smart
Folders are horribly broken.

travisn

unread,
Nov 3, 2009, 6:23:38 AM11/3/09
to OpenMeta
I use Finder Smart Folder quite a bit also. This is a serious
issue...


On Nov 2, 6:58 pm, "Jon Stovell (a.k.a. Sesquipedalian)"

Jon Stovell (a.k.a. Sesquipedalian)

unread,
Nov 5, 2009, 3:23:23 PM11/5/09
to OpenMeta
Any comment, Tom? Obviously I don't expect an instant fix for this,
since it is all part of a larger, tricky issue, but some indication of
what you are thinking would be nice.

On Nov 2, 9:58 pm, "Jon Stovell (a.k.a. Sesquipedalian)"

mc23646266

unread,
Dec 8, 2009, 9:38:26 AM12/8/09
to OpenMeta
maybe a bit OT, but anyway:

should I have an 'OpenMetaSpotlight.mdimporter' in /Library/Spotlight
or ~/Library/Spotlight ?

Or is the recommended way to delete those importers and rely on
the .mdimporter inside the various apps.
Which file gets precedence?

greetz

=:-)f

On 5 Nov., 21:23, "Jon Stovell (a.k.a. Sesquipedalian)"
Reply all
Reply to author
Forward
0 new messages