Issue with Setting Color on a File?

I've got a situation where it looks like rule sets are not getting fully processed, and it only seems to miss the part of setting a color label. I'm using the color label as indicators of job status, so it's sorta critical.

Here's the rule set:

If [all] of the following conditions are met for [the file or folder being matched]
- [Extension] [is] [mp4]
- [Color label] [is not] [green]

Do the following to the matched file or folder:
- [Copy] to folder: [FOLDER THAT IS ONE LEVEL DEEPER] (Options - If file exists: [rename])
- [Set Color Label] [green]
- [Send Growl notification] with pattern: ["file" has been processed.] (Options - None checked.)

Files get matched and all rules get triggered except for setting the color label. The file gets copied; the Growl notification gets sent. Just no color change.

Thoughts?

If the Growl message is getting sent, since that action is after setting the color, that means the coloring operation was successful. You may want to double-check the logs but I suspect from Hazel's viewpoint, everything went ok.

What kind of filesystem are you running this on? Have you tried setting the colors on those specific files yourself in Finder?

Mr_Noodle wrote:If the Growl message is getting sent, since that action is after setting the color, that means the coloring operation was successful. You may want to double-check the logs but I suspect from Hazel's viewpoint, everything went ok.

What kind of filesystem are you running this on? Have you tried setting the colors on those specific files yourself in Finder?

That was my thought, as well. Which is what makes it all the more baffling. I even went so far as to kill the rule, build a new one in its place, and I'm still seeing the behavior. None of my other rules that use a similar coloring scheme have this issue, it's only this one ruleset.

It's on a Mac OS Extended (Journaled) file system. I can manually update the color labels on those files (and have been lately to address this missing color problem).

Here's the scrubbed log snippet. Note that there's a separate ruleset on the folder "converted" that gets fired, and that's where PID 64070 comes in. Not sure if it's related, but thought it might be worth showing for completeness sake.

Hazel sure thinks it worked.

Code: Select all: 2012-06-24 23:42:10.664 hazelworker[64056] newfile.that.has.many.parts.to.the.name.mp4: Rule Bounce MP4's to "converted" matched. 2012-06-24 23:42:16.800 hazelworker[64070] Processing folder converted 2012-06-24 23:42:18.999 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:21.019 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:23.021 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:27.024 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:31.027 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:39.031 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:47.034 hazelworker[64070] File newfile.that.has.many.parts.to.the.name.mp4 is busy. Skipping for now. 2012-06-24 23:42:52.488 hazelworker[64056] [File Event] File copied: newfile.that.has.many.parts.to.the.name.mp4 copied from folder /Users/username/Desktop/completed_projects to folder /Users/username/Desktop/completed_projects/converted. 2012-06-24 23:42:52.730 hazelworker[64056] Hazel Alert: newfile.that.has.many.parts.to.the.name.mp4 has been processed. 2012-06-24 23:42:52.730 hazelworker[64056] [Custom Message] Hazel Alert: newfile.that.has.many.parts.to.the.name.mp4 has been processed. 2012-06-24 23:42:53.835 hazelworker[64056] Sending metrics to scheduler. Next scheduled run: 2012-06-26 19:36:03.000

AH HA!

I just recreated this ruleset and reconfirmed the behavior is not working as (I) expected. However, this time I killed the follow up rule that would work on the "converted" folder. Turns out, Hazel is doing this:

1. Copy file from containing folder to new folder, thus creating a new one in the new folder.
2. Change the color label of THE NEW FILE, ignoring the original file that the rule matched against.
3. Send the Growl notification.

Is this the intended behavior? My goal was to get the original file to have a new color label, not the newly created file.

Yes, that is how it works. Actions after the copy action operate on the copy.

Mr_Noodle wrote:Yes, that is how it works. Actions after the copy action operate on the copy.

How would one set up a rule that performs the action on the original then? I have a rule set up to copy files to a Dropbox folder, and once copied I want the originals to get a color label change so I can then sort them into an archive (within the original folder).

To me, the default behavior is not intuitive because technically the rules should be acting on the original file, and if I want to set up rules for the new/copied files, I would set up a rule for the destination folder. Hence my confusion

If you could explain the thought process behind the default behavior, it would be very appreciated!

I think I figured it out, re-read your answer and "actions after the copy action operate on the copy" seems to clear things up