![]() I have demoed Keyboard Maestro, but found it very confusing and also it seemed to be the opposite of Hazel: actions instigated by the user rather than automated by system events. The suggestion wasn’t to buy a license just to solve this one issue, but that it may solve this issue and offer additional functionality. While I would agree that Hazel would be overkill for solving this one single situation, which agreed should be achievable with a Folder Action, I still find it valuable for many tasks on the Mac. If this turns out to then be true for AppleScript-led folder actions, I’d probably go on a personal mission to find out exactly which API Hazel is using to monitor for filesystem changes (the two methods I’m aware of are FSEvents and the Endpoint Security framework, but I’m not sure what each of these can do that’s exclusive of the other with respect to file system monitoring). If none of this happens for iPhone syncs but it does for manually-added files, then I would be very, very interested, because it means Hazel can somehow detect the appearance of files that macOS doesn’t expose to Automator. If they do, then the diagnostic workflow I suggested will either result in one file if triggered either at the start of the end of synchronisation (the contents of this file will clarify which) or it’ll result in two or more files, which should contain the placeholder file path in all but the final output file, which should contain the file path of the fully-downloaded file once transferred across from the iPhone. It’s very quick and simple, although it provides only the first two clues, namely, whether or not iPhone-synced files can and do trigger a folder action. The first step in finding out is to do a diagnostic test as intimated by for which I decided to try and spare the ball ache of figuring out how to do so, which I hope I’ve been able to clarify the procedure for him. This is, indeed, a very reasonable explanation for what could be happening, although it’s not the only explanation. Re-reading my reply above, it perhaps sounds as though I was disagreeing with your hypothesis, so just wished to clarify that I don’t. Indeed, many users run both Hazel and KM in parallel, but that’s kinda like taking your TV into the cinema so you can watch both.Įssentially the rule was being matched and the actions applied, but the system had “locked” the file from being modified (renamed etc). If, at some stage, does wish to invest in third-party software capable of providing the functionality of Folder Actions and the simplicity of Hazel, but also a ton of other automative stuff that isn’t something otherwise achievable to users with the ready-available features built-in to macOS, then he will get more bang for his buck by looking at Keyboard Maestro. There might be a very simple fix for his Automator workflow that just needs a little bit of investigation to see what the actual issue might be. I think Hazel is a complete waste of money and would recommend that hold on to his cash. And I completely understand why one would not wish to spend money on a third-party solution for the sake of a single feature that, in principle, is a feature already built-in to macOS (albeit it without the fancy user interface that makes it easier to do things). The difference in this situation is that has found that Hazel seems to trigger appropriately whereas the Folder Action does not. If you open the file, you’ll find the file path or paths of whatever triggered it. The file will be named "triggered_at_." where the suffix will be a date-time string ( yyyymmddhhmmss) that tells you exactly when the trigger fired. Every time this happens, you will find a file appears in your ~/Documents folder (you can change this to something else if you prefer). After saving, you can add files manually to your watched folder or sync files from your iPhone so they appear in the watched folder. Therefore, if you were to open the workflow in Automator for editing, you can deactivate all of its current actions (this is just to spare the hassle of deleting them and later having to recreate them-either way, they need to not be functionally affecting this diagnostic test), and insert the action I proposed at the top. In order to diagnose the problem with your workflow, you must first establish whether these iPhone files trigger the folder action at all, which isn’t something you can discern from your present workflow. You currently have a Folder Action set up to watch for file addition to your iCloud drive. ![]() This workflow, if implemented as a Folder Action, will report exactly when the action (rule) got triggered as well as the item or items responsible for triggering it. It was originally suggested by that you test whether your watched folder gets triggered and to determine what things are responsible for triggering it.
0 Comments
Leave a Reply. |