Allow manual editing of UTIs in File Types fields

[deanishe]

It's unfortunately relatively common for apps to declare non-standard (i.e. wrong) UTIs for common filetypes.
 
OPML is a common victim, as are Markdown and Matroska.
 
When dragging files into a File Types field (in a File Filter or under the Advanced options for Alfred's Default Results), Alfred may or may not use the "right" UTI (i.e. the same one as mdls).
 
If Alfred chooses an unwanted UTI, you can change it by hand in info.plist in the case of a File Filter, but there's nothing you can do about the Default Results (as far as I can tell).

 

The proper solution is for the developer of the app responsible for the rogue UTI to fix their app, but this doesn't always happen, and rarely rapidly.
 
This issue would be relatively simple to work around if it were possible to manually edit the UTIs in File Type lists.

[deanishe]

It occurs to me that this would also make it possible to do extremely useful things like specify "public.movie" or "public.audio" as the UTI. Currently, it's a PITA to make a File Filter for video or audio files without editing the info.plist.

Edited July 4, 2015 by deanishe

[Andrew]

I'm going to look at adding this soon... I've had a long created ticket for this and never got around to it

[deanishe]

Marvellous!

[Andrew]

You should now be able to manually add and edit UTIs in the 2.7.2 b400 pre-release, available in Alfred's update prefs

[deanishe]

Marvellous. That's very handy.

 

A useful stop-gap in my one man crusade to get app developers to stop defining their own UTIs for common formats.

[mperezi]

I know this is an old thread but I'm facing this problem still in 2019.

 

The thing goes like that:

• I create a workflow with a File Action for YAML files.
• I drag a .yml file into the box and it says "org.vim.yaml-file". 
• The workflow runs fine.
• Then I install these workflow on another computer.
• It doesn't trigger.
• Find out (mdls) that kMDItemContentType is "dyn.ah62d4uv4ge804550"

 

The question is: do I have to instruct the users of my workflow to drag a .yml file after installing it? isn't there any way around this? (actually that's two questions)

Edited May 30, 2019 by mperezi

[dfay]

looks like you need to rebuild launch services. those dyn utis are a sure sign.

[mperezi]

wow, that was quick!

 

But what if I have .yml files registered with another application on my other computer? The UTI will be different, won't it?

[deanishe]

3 hours ago, mperezi said:

wow, that was quick!

 

But what if I have .yml files registered with another application on my other computer? The UTI will be different, won't it?

 

In theory, no. Developers aren’t supposed to invent their own UTIs for file formats they didn’t originate.

 

That is to say, whichever version of vim you have that’s giving *.yml files an org.vim.* UTI is wrong. It’s not vim’s file format, so it has no business assigning a vim-specific UTI.

 

Unfortunately, developers do this quite a lot.

 

Also, dyn.* UTIs are not meaningless. If no “real” UTI is defined for *.yml, macOS gives it a dyn.* UTI that says “extension=yml”. So the files will get the same dyn.* UTI on every system.

 

The best solution is to just include all of the UTIs you find for *.yml files in your workflows.