Custom QuickLook plugin for SMB mount point

[viral_mutant]

I am new to Mac OS world, so please ignore my naivety.

I am having trouble trying to understand QuickLook thumbnail/preview behavior on SMB mounted paths. From the network trace, it seems to generate the thumbnails, the entire image/pdf file is being read(I checked Wireshark). For MP4 files, a lot of data is being read(not sure exactly how much).

But this behavior is troubling as it delays content listing and generates unnecessary traffic. I have a dedicated thumbnail server as well and I was hoping to implement my own QL generator that would be used for the files on SMB mount path. The generator can fetch the thumbnails from this server.

I am not sure if this is possible for well-known file types. Is this even doable ? Can I define my own UTI for all the files residing on SMB share and then use my custom generator for this ?

I saw that DropBox has its own QL generator as well. And from the info.plist it seems to try hooking into all the well-known file types as well. But qlmanage -m seems to be ignoring it and using the system provided generator only

 

[f54da]

Great question. I have not dabbled too much with qlgenerator but my understanding is that they're associated with a given uti type. UTI/file associations are a mess on mac, IIUC basically they're dynamically determined (by launch services framework?) based on attributes including file type, mime type, creator code, and which applications are registered for those.

For your case, I suppose what you could do is set the creator code for all files in the smb mount, and I believe the creator code takes precedence over other attributes so you can then create a quicklook plugin to handle that creator code. But it may not work, file associations have always been puzzling and the only guaranteed way I've found to get deterministic behavior is to ensure only 1 application ever registers for a given uti.

See also my previous post on https://forums.macrumors.com/threads/filename-extension-versus-filetype.2367933/?post=31724728 for more info on UTI associations.

 

[viral_mutant]

Thanks
I'll explore creator code

I came across this documentation https://developer.apple.com/library....html#//apple_ref/doc/uid/TP40001283-CJBEJBHH which I believe explains how a file UTI is determined.

It clearly says

You can’t create a Spotlight importer that overrides an existing file type. For example, you can’t write a JPEG Spotlight plug-in because Apple provides one. Only one importer is allowed per uniform type identifiers (UTIs).

My struggle is that I am trying to create an on-demand download client. But the thumbnail/preview thing keeps downloading all the files

 

[f54da]

Spotlight importers are different from quicklook plugins though. Also by setting creator code on a file you can force the UTI to be different than the default.

 

[viral_mutant]

Oh, I thought spotlight importers would determine the UTI and populate the attributes like kMDItemContentType and kMDItemContentTypeTree, isn't it ?

 

[f54da]

No, that's not the case. UTI resolution is done dynamically at _runtime_, I believe by launch services framework. There are no attributes "kMDItemContentType" computed ahead of time stored on the file (although they may be cached in a separate database just for speed). I.e. you can imagine that if the cache is currently empty and you use "mdls" on a file, the function to get the UTI of a file (which again I believed ultimately links to either CoreServices or LaunchServices) will follow the resolution algorithm specified in https://forums.macrumors.com/threads/filename-extension-versus-filetype.2367933/post-31724728.

Spotlight importers don't come into the picture at all here, aside from the fact that spotlight may compute the UTI type of a file to determine how to handle it.

UTI types are "implicitly defined" by anything that adds entries to the LaunchServices database, and the binding of a UTI to a given file is completely dynamic, at runtime (modulo any caching). This is why you will often find that if you install a new app (where "install" is just opening it once so that LaunchServices becomes "aware" the app exists), it can completely usurp file associations, causing files previously defined as one UTI to now be defined as another.

 

[viral_mutant]

Oh, I was just going by this documentation

kMDItemContentType
Uniform Type Identifier of the file. For example, a jpeg image file will have a value of public.jpeg. The value of this attribute is set by the Spotlight importer. Changes to this value are lost when the file attributes are next imported. This attribute is marked as nosearch. You must specify this attribute key explicitly in a query in order for its contents to be searched.
Value Type:	CFString
Framework:	CoreServices/CoreServices.h
Header:	MDItem.h
Availability:	Available in OS X v10.4 and later.

 

[f54da]

I think that's misleading. My reading of that is that it's effectively a "system set field" (i.e. you cannot set it directly). That is to say, during indexing spotlight will dynamically compute and cache the UTI for the file (using the lookup procedure I mentioned). This is what allows you to e.g. search and find all PDFs.


But it's not spotlight itself responsible for generating the underlying uti, it just retrieves it. I.e. you don't need to create a spotlight importer to define a new uti type or to change the UTI association for a file.

 

[f54da]

See also https://stackoverflow.com/questions/16943819/where-do-uti-come-from btw.

Really the apple documentation on UTI is pitiful (and this is back in the leopard days when apple actually put out some decent documentation!). They talk on and on about how great UTIs are, but nowhere do they discuss the actual algorithm osx uses to determine the UTI for a given file. Ultimately at the end of the day a UTI is characterized by extension, mime-type, and hfs creator code. And mime-type isn't itself something persisted directly on the file, so that only leaves extension and creator code as the determining factors. (The existence of dynamic UTIs is strong evidence that file extension and fourcc are the only input parameters. See https://alastairs-place.net/blog/2012/06/06/utis-are-better-than-you-think-and-heres-why/

And of course all the documentation assumes that there is a unique 1:1 mapping between things. They never discuss what happens if two different apps claim different UTIs for the same file extension. As I mentioned in practice the resolution algorithm seems to be same as what launchservices to determine the "open with", so probably an authoritative app gets assigned in that fashion.