Filename extension versus Filetype

[Gudi]

I need to understand how macOS associates filename extensions with filetypes.

One of my Macs links *.mkv files with the filetype "Matroska Video File" and the other Mac with the filetype "Matroska video". Both filetypes open the IINA video player app, but only the later filetype also generates little thumbnails for the Finder icons.

So how can I change the filetype associated with the extension .mkv?

 

[Gudi]

Apparently what should be happening is that the filetype switches back and forth depending on the opening app. But on my other Mac it always stays "Matroska Video File", even after deleting VLC.

 

[bogdanw]

Try to rebuild the Launch Services database, from Terminal https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/ or with Onyx https://titanium-software.fr/en/onyx.html

 

[Gudi]

Try to rebuild the Launch Services database, from Terminal https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/ or with Onyx https://titanium-software.fr/en/onyx.html

I tried both several times over already. And I used 'AppCleaner & Uninstaller' to delete every single file of VLC and IINA. The problem remains that there are four different filetypes associated with the extension .mkv including twice 'Matroska video' (which is the type introduced by IINA). But the one actually linked to my files is 'Matroska Video File'.

The thumbnail cache is actually growing with every video I open in IINA. You can see it in the Preferences ⌘+, under Tools. The thumbnails just don't show up in the Finder.

 

[Gudi]

Declare Uniform Type Identifiers in Info.plist · Issue #1623 · iina/iina

System and IINA version: macOS 10.13.4 IINA 1.0.0-beta1 Expected behavior: Since IINA strives to be a good macOS citizen we should declare UTI for media formats in app Info.plist. This info is used...

github.com

So I assume it's a problem with the Unified Type Identifier (UTI) io.iina.mkv declared by IINA.

 

[bogdanw]

You can try to make all mkv files open with QuickTime, then go to IINA – Preferences – Utilities and Set IINA as the default application.

 

[Gudi]

You can try to make all .mkv files open with QuickTime, then go to IINA – Preferences – Utilities and Set IINA as the default application.

And that's how it should work, but it doesn't in my case. The Filetype always stays the same, even if I make Handbrake the standard opening application. No difference whether I use IINA's preference window or the Finder's Info panel. Maybe it's a bug of macOS on arm64?

 

[Gudi]

PROBLEM SOLVED

Turns out it was always the QuickLookVideo extension (not IINA), which made working with .mkv files in the Finder so much more pleasurable. I highly recommend installing it.

https://github.com/Marginal/QLVideo

 

[Fishrrman]

There is an old, but still usable (at least up to and including Mojave) preference pane called "rcdefaultapp" which is superior to anything else out there.

It's now discontinued by its author but it's still available here:

RCDefaultApp 2.1 (Mac) - Download

Download RCDefaultApp for Mac - System Preferences pane that offers you control over which applications should be used by default when dealing with certain file types

mac.softpedia.com

I suggest that you download it and give it a try.
It may do "all that you need"...

 

[bogdanw]

It's now discontinued by its author but it's still available here:
[mac.softpedia.com/get/System-Utilities/RCDefaultApp.shtml]

It’s still available on the developers’s website and it’s working on Big Sur/Intel
https://www.rubicode.com/Software/RCDefaultApp/
https://forums.macrumors.com/threads/how-to-set-adobe-reader-to-default.2365430/post-31620670

 

[f54da]

Use mdls to find the UTI hierarchy of a file. As to how this UTI hierarchy is determined, it's a huge mess. File types are mapped to UTIs that can be declared by applications, unknown file types are mapped to dynamic UTIs, throw in some nondeterminism based on which app registers the UTI first (or last) and it's always a headache. The only way I've reliably been able to ensure file icons and "open with" are properly associated is to make sure only one application exports the UTI, and only one application registers an icon for the UTI by manually editing info plists.

Identifying file types: UTIs, filename extensions, and another free app

What to do when you need to use Uniform Type Identifiers, only to discover that Apple’s reference manual hasn’t been updated for nearly 9 years: write an app!

eclecticlight.co

See also https://tidbits.com/2009/09/06/snow-leopard-snubs-document-creator-codes/

For individual document files (whether specified by a file-system reference or a URL with scheme file), the criteria are as follows:


1. If the user has specified an explicit binding for the document (or for the entire document type to which it belongs), the preferred application is the one the user has specified.
2. If the document has a filename extension (or if one has been specified as a parameter to LSGetApplicationForInfo), find all applications in the Launch Services database that claim to accept documents with that extension.
3. If the document carries a four-character file type (or if one has been specified as a parameter), find all applications that claim to accept files of that type.
4. If more than one application has been found as a result of steps 2–3, apply the following criteria in the order shown:

• 1. If the document carries a four-character creator signature (or if one has been specified as a parameter), give preference to any application that claims to accept documents with that signature (typically the application to which the signature belongs).
• 2. Give preference to native OS X applications over those that run in the Classic emulation environment.
• 3. Give preference to applications residing on the boot volume over those residing on other file-system volumes.
• 4. Give preference to applications residing on a local volume over those residing on a remote volume.
• 5. If two or more versions of the same application have been found, give preference to the one with the latest version number.

If two or more candidate applications remain after all of the foregoing criteria have been applied, Launch Services chooses one of the remaining applications in an unspecified manner.

 

[Gudi]

The only way I've reliably been able to ensure file icons and "open with" are properly associated is to make sure only one application exports the UTI, and only one application registers an icon for the UTI by manually editing info plists.

See also https://tidbits.com/2009/09/06/snow-leopard-snubs-document-creator-codes/

Interesting. So how does this work? I go to the ~/Applications folder, open the application bundle (for let's say VLC) find the Info.plist file and delete the UTIs for all the filetypes, which I don't want the app to claim ownership of. And then (after a reboot I suppose) the app is unable to interfere with these files Finder representation? Until the app gets an update and then everything starts all over again? 🤔

 

[f54da]

@Gudi Basically yes. It's more annoying on newer versions of osx because modifying info.plist breaks resource signature, so if the app actually validates this it'll be an issue. In practice I don't think most apps validate resource signature though, and gatekeeper doesn't complain if it was an app you've previously launched (or at least it used to be the case, not sure how it is now).

Usually there'll be a CFBundleDocumentTypes section, and maybe an imported or exported UTI section. The structure should be self-explanatory. If you do want the app to be able to handle it but not associate its icon with it, you can just remove the icon tag. Once you go through and clear them out, you have to reset launchservices DB, just google around for that command (it's lsregister something something). And yes, if the app updates or you download a new app that decides to again claim ownership of the UTIs, you have to repeat the process. But this is the only way I've found for the associations to be deterministic (by which I mean I can reboot or nuke launchservice db and both file associations and file icons will remain unchanged. Similarly if I decide to one day open a file in a non-default editor, the file icon remains associated with its default editor).

Honestly the entire UTI/launchservice DB is probably the only major architectural decision I feel osx did poorly. It's akin to a black-box registry that the user has no control over, and it's just an absolute pain for both developers and users.

Edit: Oh, for extra fun don't forget that quicklook generators can also export UTIs. If you want to use quicklook generator for file type X without also overwriting the uti of X, the only way I know of is to modify the plist of the quicklook generator and make sure it doesn't export its own UTI.