On July 1, 2016, at 12:52 PM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
>On Jul 1, 2016, at 09:18 , Matthew LeRoy <mle...@minitab.com> wrote: > > > Steps to troubleshoot/rectify the issue? > > > >Since it’s hard to find out what’s going on with UTIs, I suggest you start by >making sure your assumptions are correct. I’d try getting rid of the app that >has the imported UTI declaration (e.g. zip the app and delete the unzipped >original), then > verify that the extension for that imported UTI no longer works, AND make > sure that the extension for the exported UTI in the other app really does > work. > >(There could be another app that exports the “wrong” UTI instead of importing >it. Or the intended exporting app may be doing-it-wrong. Either of those could >produce the symptoms you’re seeing.) > >If the correct UTI works for the exporting app when it’s unconflicted, then I >don’t see what you can do except submit a bug report. However, when both apps >are present, the extension that Launch Services recognizes may depend on the >order of app > installation, or on the file system date of the app. One of those things > could lead to a workaround, with a bit of experimentation. Just to clarify, there’s only one file extension in question here. The two apps in question are ours — which owns/is authoritative for our file format -- and a competitor’s app which can open our file format. Our app declares an exported UTI for our file format, while the competitor’s app declares an imported UTI for our file format with the same file extension but with a slightly different UTI string (kMDItemContentType). The issue, it appears, is that Launch Services has to choose which UTI to use for files with that extension, and it’s choosing the imported UTI from the competitor's app rather than the exported UTI from our app, even though the docs explicitly say that Exported UTIs take precedence over Imported UTIs. I will note that the competitor’s imported UTI lists the file extension (under the UTTypeTagSpecification key) via both public.filename-extension *and* com.apple.ostype, while our exported UTI lists it only via public.filename-extension — could that perhaps have anything to do with why LS is choosing the imported UTI over the exported one? Further complicating matters is that this scenario was discovered on a customer’s machine, so we don’t have the ability to do much in-depth troubleshooting. We tried the usual `lsregister -kill -r -domain system -domain user -domain local` to see if a complete rebuild of the LS database would get it to choose the exported UTI instead, but no luck. I was hoping there was some way to force LS to use the UTI from our app rather than the competitor's app, perhaps via `lsregister` or some other command, but haven’t had any luck there, either. Thinking about this some more, there doesn’t appear to be any mechanism that prevents an arbitrary application from “hijacking” a file type it doesn’t own by declaring a UTI (imported or exported) with different UTI property values. In fact, I found this thread from 2014 that appears to speak directly to this issue: <http://prod.lists.apple.com/archives/cocoa-dev/2014/Jun/msg00112.html>. Our app does not override typeForContentsOfURL:error: as that thread seems to suggest it should. However, even if it did, it still wouldn't solve the problem of our files being gray/unselected in the Open panel because the Open panel doesn’t call that method to determine the UTI for every file it lists; rather, it appears to call directly to LS outside of the app, and LS will continue to give it the ‘wrong’ UTI info. Short of passing the file extension to runModalOpenPanel:forTypes:, instead of passing it the UTI like we do now, I can’t think of a way to prevent/fix this apparent (and fairly serious) flaw. Matt _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
