OpenMetaSpotlight.mdimporter v. 3.0 breaks existing Smart Folders

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.
Original issue reported on code.google.com by jonstov...@gmail.com on 3 Nov 2009 at 3:00
neumannjmt / openmeta

OpenMetaSpotlight.mdimporter v. 3.0 breaks existing Smart Folders #16
