Error with macro. Can't understand what's going wrong [SOLVED]

I have this simple macro to backup 2 folders everyday, but sometimes I get an error.

Backup Loopcloud (available via Raycast).kmmacros (27 KB)

Once that runs, I have a Hazel rule to rename both folders:

But sometimes I get this error:

2024-04-02 06:05:59 Execute macro “Backup Loopcloud (available via Raycast)” from trigger At 6:06 AM every day
2024-04-02 06:06:01 Action 15608305 failed: File action failed because destination already exists /Users/dannywyatt/My Files/Backups/Loopcloud/User Library/Loopcloud
2024-04-02 06:06:01 File action failed because destination already exists /Users/dannywyatt/My Files/Backups/Loopcloud/User Library/Loopcloud in macro “Backup Loopcloud (available via Raycast)” (while executing Copy File “~/Library/Loopcloud”).

You can see that in Finder, the folders that go to the System Library have sequential dates and always run around 6:06 am as expected. But then User Library seem to skip some dates and the times they have are not always 6:06 am or even close to that time.

Anything you can see that I can't?

What's triggering the Hazel action? My guess is that that isn't running, the folders don't get renamed, so the next day's KM macro fails because the folder already exists.

Consider removing all doubt by doing the renaming as part of the KM Copy -- you only (perhaps should only) need to date-stamp the "Loopcloud" folders, not their sub-folders, so that'll be easy enough to do. Something like:

...which would give you Loopcloud 2024-04-01, Loopcloud 2024-04-02, etc folders in your backup location (change the ICUDateTime format specification to get the date added how you want).

1 Like

But that if that was the case, then the System Library wouldn't work either, but it is, as you can see in the screenshot. That's why I don't understand what's happening...

I don't know if you're familiar with the app, but Hazel is always triggered when there's a new file in a specific folder. Once that happens, it checks the rules and applies whatever action(s) we have at the end. So basically there's only 1 trigger: when there's a new file in a folder.

I do that sometimes, but not always. I didn't know you could add the date directly in the action like that. I always used this set of actions (saved as a favorite), because in the past that's what someone else suggested, when I wanted to add the current date:


So it became kinda of a "burden" to me every time I wanted to add the date to a macro. But I guess this approach above (my approach) is for a different scenario?

I already saved the token you mentioned, as a snippet %date to make it easier and faster.
And since I'm in the process of reducing the amount of Hazel rules as much as possible, relying more on KM instead (whenever I feel like KM does the exact same thing and where I spend 99% of the time when it comes to automating tasks), your solution is just perfect!
Thank you so much for sharing that :raised_hands:

Yes, I should have said "failing" rather than "running". You're processing sub-folders -- I don't know how Hazel will react if it can't rename something (perhaps still being copied), perhaps it doesn't rename the parent?

Whatever's going on, the answer is likely in the Hazel logs so have a check there if it's bugging you.

Only from what you guys here have said, so I don't know if folder changes are the only trigger. I think you can run rules from AppleScript, for example.

Yeah... Not sure why that's doing what it is. It might be to make things more obvious and/or easier to change -- you don't have to hunt through a macro to find all the date/time tokens if you decide you don't need seconds after all -- or maybe taken from something that used run-time dialogs to let the user select their own format.

Do have a look at the ways you can format the date/time slug the ICUDateTime token produces -- it's really customisable. But not always obvious, so shout if you get stuck.