Hi, sorry for the long delay. I’ve been moving home, moving job, and even slept in my car for two nights in between signing tenancy agreements.
Well, anyway, it looks like the debugging was briefer than it could have been. That’s your culprit. The Filter Finder Items was the one action more than the others that I quietly suspected was going to be a problem.
In the first test run, your workflow was triggered twice: once by the placeholder file, and once by the synced image file.
In this test run, your workflow only triggered once. My guess, given that the trigger file created was empty, is that it was triggered by the placeholder file, but not the final synced file.
This is seeming to me like an problem with timing. My hunch is that the workflow stands a risk of being triggered successively in a very short amount of time. The first time it gets triggered is going to create a bit of a bottleneck in terms of processing power, speed, resources, etc. which Automator’s background helper (Automator Runner, which is responsible for executing application extensions, such as an Automator workflow that runs outside of the Automator app environment) is consuming as it instantiates an
AMWorkflow application process within which your workflow gets run. By this time, the file has synced, and another signal is fired that should trigger your workflow a second time. Clearly this can occur in sequence and in time, as demonstrated by the first test run. But, depending on what else is happening in MacOS at any given time, execution speeds will vary quite substantially.
The other limiting factor on speed is the first action in your workflow. I already know that this action is slow. It won’t necessarily appear so if you run it within the Automator environment, but that’s because it already has everything loaded into memory and ready to go. In practice, it’s a bit of a nightmare. I’m fact, all of the Finder-specific actions are woefully inefficient. They’re created in Objective-C code, I believe but, as the name suggests, it doesn’t actually levy the speed and power of low-level file system access that Objective-C permits, instead operates through the Finder (which was written in QBASIC, I’m told), possibly by way of Apple events, which is the only way I am aware of to do this sensibly, and beneath that I’ll wager is a poxy uncompiled AppleScript that won’t be written very well (ironically, the people who created AppleScript are terrible at writing scripts with it).
I’m surmising that we have a folder action that triggers with the appearance of the placeholder file. This is where everything takes forever to get up and running, and to actually run. But a microsecond after the placeholder file appears, it is replaced with your synced file. This sends off a second signal to trigger the workflow that’s still not actioned the first trigger yet. Potentially—and this happens a lot in many different contexts, though I haven’t specifically confirmed is definitely happening here, but it is a possibility—the second signal gets fired during the instantiation of the
AMWorkflow runner environment, or some similarly-sensitive or critical moment in which the system isn’t able to create a second, concurrent runner environment, and ends up discarding the second signal as a failure to launch. It may even not process the second signal at all at specific times, and end up missing it while distracted by how terrible Catalina is.
To test, or not to test…?
To get some sort of indication that any part of this explanation is in the ball park, you may choose to run a few more tests. If you ran the same identical test a few times, my prediction would be for some of these runs to yield the empty trigger file you got on this occasion, and some of them to have the filepath to your synced image. If so, for me, that would conclude the testing, and we could reasonably assume the above is accurate. If not, it would be interesting to find out what happens when you sync a larger file, say 100MB in size. Of course, you’d need to adjust the filter, which I recommend filters by file extension rather than
kind, as it’s never convincingly clear whether
image kinds include the other subcategories of kinds that are named specifically for an image format, e,g,
Compuserve GIF, etc. which Finder lists as separate kinds. Add to this that it’s essentially running a spotlight query, and if the file that appeared isn’t indexed by the time the action runs, it conceivably could get missed. You’ll also have had experiences searching in a Finder window for a file name fragment that you know has at least one positive match (probably in that very window), yet Finder can’t seem to get it.
The point of using a larger file to sync is to put as much time between the two trigger events as possible. You may even find that it triggers more than twice. I would not be surprised if every few megabytes of data that gets written to the placeholder file, it updates the Finder, which interprets the changed file as, essentially, the appearance of a new file. So you could even add in a second filter to include the file extension of the placeholder file (just for testing purposes).
By now, this is probably seeming more hassle than it’s worth. If you haven’t really done much debugging yourself in the past, it probably does seem like a lot of effort. Coupled with the amount I write in a single post, this might lead you to rethink shelling out money for Hazel that you know worked out of the box.
If you do this sort of thing enough times, it’s actually a simple, systematic process, that unfortunately, being guided remotely, and with a 12 day gap, makes what would really be a 20-minute job span out over days.
So if you want to run those additional tests I described just now, either for the curiosity, practice, or fun of it, or to reveal that nothing I said might happen actually happens, then it’ll be a good academic exercise and interesting to hear what the outcome is. But, I think you just want this bitch to work…
So let’s do that.
Close Automator. Delete your workflow. It never exksted.
Open up Script Editor. Create a new, blank document. Copy and paste this AppleScript:
…to be continued…