I’ve been using a macro that I found here and it’s now stopped working. It looks like this:
and the Get Content Kind action now fails causing the macro to abort. I’ve tested the action with various files - jpg, png, txt and pdf and they all result in failure.
Can anyone offer an explanation?
This Action is working for me:
Have you examined the Action with a literal path of a file you expect to find?
Yes - just running the action on its own, as you have, with lots of different files results in the action failing. It’s not just “kind” either but “type” too!
Have you tried the std troubleshooting methods:
What versions of KM and macOS are you running?
Engine and Mac restarted.
KM v 9.0.5 macOS Mojave 10.14.6
Here's the test macro:
And the KM log output:
(sorry about the size of it!)
That is very strange.
Just to double-check the obvious, did you get the paths shown in the Actions using the "Folder" button to get a file? IOW, have you made sure the path is valid?
If the paths are valid, then I'm out of ideas. Maybe @peternlewis will have an idea.
I would guess Keyboard Maestro does not have permission to access the Desktop.
There is a specific permission for allowing an app to access the Desktop, and presumably Keyboard Maestro does not have it.
I don't know how to allow that specific permission if the system is not prompting you, so probably the easiest (and probably best) solution is to just enable Full Disk Access to Keyboard Maestro and Keyboard Maestro Engine - but note that there are security implications in this.
To @JMichaelTX: have tried using the "folder" button in the action to get the path and the result is the same, i.e. the action fails.
To @peternlewis: the problem is not limited to Desktop items - it happens regardless of where the file is located on my hard drive. I've also tried it with files on removable media, for example /Volumes/Taj/Mac Apps/AccountEdge Pro/AccountEdge Pro 2014.txt and the action properly returns public.plain-text.
Using Finder's contextual "Get Info" also works fine for any file that I choose.
On my Mac, I've always given KM Full Disk Access from day one so I've tried removing that and reinstating it, but that hasn't made a difference either.
The macro that this all started with was working fine until only very recently so I suppose that I must have done something to change that - like install an app or change a system setting. I have been installing a lot of demo apps recently in connection with looking for an Evernote replacement so maybe that's had an effect.
So I'm going to try to backtrack to find out what I've been doing to my Mac but in the meantime if you have any other ideas I would be really interested to hear them!
When I find out what the cause is I'll be sure to post it up here.
Cheers from a breezy UK.
OK, @JMichaelTX, @peternlewis so I've tracked back to what I've been doing on my Mac and I can't find anything at all that might have caused the problem I am experiencing.
I want to provide a bit more information that will allow me to promote this problem to a "BUG" 
- here goes.
I've created a test macro with 2 sections in it:
an AppleScript action that extracts the content type from files selected interactively and displays the result.
a KM action group that does the same thing (more or less) as the AppleScript section but using KM actions.
Here's the macro: Test of Content Type Detect Failure.kmmacros (5.0 KB)
For clarity, this is the AppleScript section:
and here is the KM Actions group:
and this is the output displayed by the two sections:
For completeness, the KM Actions group requires a Finder selection and this is what that looks like:
which is the same 4 files I selected when the AppleScript section ran.
As I've noted before, this problem is not unique to my Desktop folder - it happens with files anywhere on my Macintosh HD, but does not happen with files on externally-mounted disks.
As far as I am aware, these two sections of the test KM macro should be displaying the same thing in terms of file content kind, but while the AppleScript part works fine, the one that uses the built-in KM Action does not work at all.
I am therefore now calling this a bug and ask for it to be investigated further, please.
Something is going on, but I don't think it is a KM bug. I tested your macro and it works fine, which is to say it produces the result you were hoping for on my machine (i.e. my Mac HD). I know that doesn't solve your issue, but it does seem to suggest it is something specific to your Mac (esp. because the macros works on your external drives). What that might be, I have no idea.
The file type is gotten from the Spotlight database, so my guess is there is a corruption or other problem with your Spotlight database.
The code in question is trivial:
MDItemRef mdItem = MDItemCreate( kCFAllocatorDefault, CFBridgingToCFString(path) );
if ( mdItem ) {
CFTypeRef mdAttr = MDItemCopyAttribute( mdItem, kFileAttributeMDItemKeyArray[int(mAttribute)] );
so there is not really a lot of scope for a bug to hide.
Presuming other attributes like create data work (so the path is correct), there really isn't anywhere I can see for a bug to hide.
If it is the Spotlight database, then you might also see failures in the content kind, comment, added date, downloaded date, and where from attributes.
Rebuilding your Spotlight database might resolve the issue.
Thank you @rolian for taking the time to explore my issue. I’m glad it works for you and I agree with you that it is specific to my Mac.
Thanks for the input @peternlewis. That’s given me another avenue to explore! Having never knowingly done anything to/with Spotlight I’ll see if there’s something I can find.
I still confuses me that if the information is obtained from the Spotlight database then why can AppleScript do it successfully while KM can’t as shown by my test macro. Does AppleScript get the information from somewhere else, then? Or what? Another KM user (@rolian) has kindly shown that this all works without a problem on their Mac so it is likely to be specific to my machine, but the mechanism behind issue is hardly clear to me.
Thanks to all of you @peternlewis, @JMichaelTX, @rolian for your contributions to helping me solve my problem.
I followed @peternlewis suggestion and rebuilt my Spotlight database and now the KM action to get content type and content kind work fine as does added date.
There are still others that don't work - like where from and downloaded date - but I'm not worried about them right now as they're not the ones given me a problem!
Most files don't have where from and downloaded date, and they may well not be preserved across a spotlight rebuild.
I assumed that was the case but not knowing the ins and outs of MacOS in detail I was just happy that your suggestion worked.
Slightly off-topic, I know, but I don’t think it is said enough: KM is a fantastic product!
So, thanks again @peternlewis 