Unexpected Copy Behavior

Talk, speculate, discuss, pontificate. As long as it pertains to Hazel.

Moderators: Mr_Noodle, Moderators

Unexpected Copy Behavior Thu Feb 14, 2013 12:24 pm • by sstorkel
I ran into some... interesting... behavior with the Copy action that I thought I'd describe. I tend to think that what I ran into is a bug, but after looking through Hazel's documentation I see that it is the expected behavior.

Background
I have Hazel 3.0.16 installed on an iMac running Mac OS 10.8.2. I was trying to create a rule to help manage the files on my Garmin Edge 705 bicycle computer. For those of you who aren't into expensive biking gadgets, the Edge 705 records GPS positions and other data (speed, cadence, heart rate, etc) during a bicycle ride. Once the ride is finished, you can connect the device to a computer via USB and download the data files for display and analysis.

Goal
I wanted Hazel to do three things with files on the device:
  • Copy the files into Dropbox, so I'd have a backup
  • Copy the files to a particular folder on my computer
  • Delete the files from the device, to make room for additional data

Matching
I created a rule for Hazel to monitor the folder on the device that contains the data files. There were two conditions for the rule:
  • Extension is 'tcx'
  • Date Added is after Date Last Matched

Processing
I created processing actions to mimic what I described above:
  • a Copy into Dropbox
  • a Copy into a particular folder on my computer
  • a Move of the file to the Trash

Expected Result
I expected that when the rule fired the following would happen:
  • A copy from the device to Dropbox
  • A copy from the device into my 'working' folder
  • A move of the file from the device to Trash

Actual Result
I was surprised to find that I ended up with a copy of the file in Dropbox, no copy in the 'working' folder, and the files hadn't been deleted from the device!

Why It Happened
Looking at Hazel's log made it obvious what was happening:
Code: Select all
2013-02-13 19:05:13.471 hazelworker[23633] [File Event] File copied: 2013-02-13-21-16-11-2.tcx copied from folder /Volumes/GARMIN/Garmin/History to folder /Users/sstorkel/Dropbox/Garmin History.
2013-02-13 19:05:13.796 hazelworker[23633] [File Event] File copied: 2013-02-13-21-16-11-2.tcx copied from folder /Users/sstorkel/Dropbox/Garmin History to folder /Users/sstorkel/Documents/Bicycle/Garmin History.
2013-02-13 19:05:14.174 hazelworker[23633] [File Event] File moved: 2013-02-13-21-16-11-2.tcx moved from folder /Users/sstorkel/Documents/Bicycle/Garmin History to folder /Users/sstorkel/.Trash.

Hazel copied the file from the device into Dropbox, then copied from Dropbox into my 'working' folder, then moved the file from the working folder into the trash.

After poking around in the documentation I discovered that the Copy action, like the Move action, causes all subsequent actions to apply to the copied file rather than the original file. This behavior makes sense for Move actions: once the file or folder has been moved, there's no use having subsequent rules fail because they're trying to access the original item. For Copy actions I found this behavior a bit... unexpected. Since the Copy action doesn't cause files to disappear, I expected that subsequent actions would continue to apply to the original file rather than the copy.

The Final Version
In any event, once I knew what was happening it was easy to revise the rules so that they worked properly:
  • Move the only copy of the original file into the Trash!
  • Copy the file into Dropbox
  • Copy the file into the 'working' folder
The ordering of the last two steps doesn't matter, but moving the file into the Trash must be the first thing action that takes place.
sstorkel
 
Posts: 2
Joined: Thu Jan 17, 2013 5:48 pm

Re: Unexpected Copy Behavior Fri Feb 15, 2013 4:34 pm • by Mr_Noodle
The copy behavior only doesn't make sense to you because in this particular case, you want it to act the other way. Consider a workflow where someone wants to copy a file then color that copy at the destination or have that copy further processed. In that case, it makes perfect sense (and from my experience, the more common case).

So yes, you need to learn to take that into account. Also, the notion of copying then deleting later is totally unnecessary. Just use move operations.
Mr_Noodle
Site Admin
 
Posts: 11196
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Re: Unexpected Copy Behavior Sat Feb 16, 2013 5:11 pm • by sstorkel
Mr_Noodle wrote:The copy behavior only doesn't make sense to you because in this particular case, you want it to act the other way. Consider a workflow where someone wants to copy a file then color that copy at the destination or have that copy further processed. In that case, it makes perfect sense (and from my experience, the more common case).

I'll buy that. I'm just pointing out: this is the one case I've run into where I had to dig into the documentation because Hazel's behavior was completely different from what I expected...

Also, the notion of copying then deleting later is totally unnecessary. Just use move operations.

Agree that this would work. I implemented Hazel actions that exactly mimic my manual workflow. As an optimization, I could have done a Move from the device to one folder, then a Copy to the second folder. Given the irreplaceable nature of the data, I don't mind having an extra copy sitting in the trash for a few days...
sstorkel
 
Posts: 2
Joined: Thu Jan 17, 2013 5:48 pm


Return to Open Discussion