Unexpected behavior when Copy followed immediately by Move

I'm noticing some odd behavior with Hazel copy rules followed immediately by move rules. (I am running the latest version of Hazel, 4.2.4.)

Let's say I have the following rule attached to my Downloads folder

If Extension is .foo
Do the following actions:
Copy to folder BarDirectory
Move to folder BazDirectory

The behavior I am expecting is this:

* copy the file from Downloads/TheFile.foo -> BarDirectory/TheFile.foo
* move the file from Downloads/TheFile.foo -> BazDirectory/TheFile.foo

However, this is the behavior that I am actually witnessing:

* copy the file from Downloads/TheFile.foo -> BarDirectory/TheFile.foo
* move the file from BarDirectory/TheFile.foo -> BazDirectory/TheFile.foo

This seems like a bad behavior to me. Should the file not be moved from its originally discovered location (in this case, Downloads)?

Here is my specific use case: I have a Synology NAS that has a built-in BitTorrent client, that watches a folder on the Synology NAS for new .torrent files, when it finds a new .torrent file there, it starts the BitTorrent transfer and then deletes the .torrent file. So I set up a Hazel rule, so that, whenever I download a new torrent file, it moves it into the folder that the Synology NAS is watching. But I want to keep a backup of the .torrent file, just in case something fails or messes up somehow, or if I want to send it to a friend or whatever. So in this case, I have two actions, one action moves the .torrent file into the Synology torrent directory, and another action copies the .torrent file to my backup directory. But I have to do the copy action before the move action, because sometimes the Synology yanks the .torrent file right out from under Hazel, before it has a chance to run the Copy action. So in my torrent rule, I have the "copy to backup directory" action run before the "move to Synology torrent watch folder" action. So I am expecting this to happen:

* copy the file from Downloads/foo.torrent -> TorrentBackupDirectory/foo.torrent
* move the file from Downloads/foo.torrent -> SynologyWatchDirectory/foo.torrent

Instead I am seeing:

* copy the file from Downloads/foo.torrent -> TorrentBackupDirectory/foo.torrent
* move the file from TorrentBackupDirectory/foo.torrent -> SynologyWatchDirectory/foo.torrent

My rule:

(the "Run AppleScript" action just uses an AppleScriptable app to play a sound effect to let me know that the torrent was successfully processed)

Log below:

Code: Select all: 2018-05-16 14:27:51.731 hazelworker[16012] CentOS-7-x86_64-LiveGNOME-1804.torrent: Rule Torrent Files - Synology matched. 2018-05-16 14:27:51.933 hazelworker[16012] [File Event] File copied: CentOS-7-x86_64-LiveGNOME-1804.torrent copied from folder /Users/dburr/Downloads to folder /Volumes/Vault/Torrents (Backup). 2018-05-16 14:27:52.030 hazelworker[16012] [File Event] File moved: CentOS-7-x86_64-LiveGNOME-1804.torrent moved from folder /Volumes/Vault/Torrents (Backup) to folder /Volumes/Vault/Torrents.

Am I doing something wrong?

Actions after the "Copy" action operate on the copy, not the original. That allows you to continue processing the file after that. In general, actions that create a new file are setup so that subsequent actions operate on the new file.

Try reversing the order of operations to do what you want.

Mr_Noodle wrote:Actions after the "Copy" action operate on the copy, not the original. That allows you to continue processing the file after that. In general, actions that create a new file are setup so that subsequent actions operate on the new file.

Try reversing the order of operations to do what you want.

Thanks for your response, however as I explained in my original post, when a file is moved into the NAS's watch folder, as soon as it notices that a new file is there, it begins processing the file, removing it from the directory. Sometimes this happens so fast that the file is deleted before Hazel has had a chance to run the subsequent Copy action.

I've worked around this for now by adding a simple "Run Shell Script" action before the Move action that does the file copy:

Code: Select all: cp "$1" "/Volumes/Vault/Torrents/BACKUPS"

All actions within the same rule are synchronous, meaning that the next one does not fire until the previous one is complete (there are complications with the "Open" action but that's not relevant here).

There might be an issue of Hazel processing the file before whatever program put it there is finished writing out to it. You can add a condition like "Date last modified is not in the last X minutes" to help alleviate that.