Can hazel tell a file is being copied?

I noticed some odd behaviour the other day which I think is because Hazel started processing a file before it had been completely copied to the monitored folder.

I'm renaming files for iTunes. I was copying a whole album's worth to a monitored folder and Hazel started processing them, but it renamed one incorrectly. I suspect because the ID3 tags (specifically album) hadn't been written yet. There are null ref mentions in the logs.

Does HFS not distinguish between a file that's being created and a file that has been created? I don't think it's Hazel's job to work around a deficiency in the OS like that so I can happily(ish) live with only handling files that were added more than a minute ago, but I was very surprised to see this happen.

So, am I interpreting what I saw correctly or could this be a Hazel bug? If it's not a Hazel bug, is there a recommended approach to avoiding this happening?

Cheers,

Nick.

Unfortunately, it's a bit of a wild west situation when it comes to filesystem stuff and apps cooperating. Certain apps have naming scheme that Hazel knows about. Otherwise, there are BSD advisory locks which are somewhat standard and most of Apple's APIs will use them automatically but there are still cases where app developers won't use them. In short, it's up to the app developer to use the locks.

The workaround for Hazel would be to add a condition like "Date modified is not in the last X minutes" to make it so that the rule won't match until sometime after it was last touched. It will result in a delay in processing but you can be more sure that it won't interfere with some other program doing something with the file.

Mr_Noodle wrote:Unfortunately, it's a bit of a wild west situation when it comes to filesystem stuff and apps cooperating. Certain apps have naming scheme that Hazel knows about. Otherwise, there are BSD advisory locks which are somewhat standard and most of Apple's APIs will use them automatically but there are still cases where app developers won't use them. In short, it's up to the app developer to use the locks.

Yeah, I'd been using Date Added, but I guess the most robust would be Date Modified, or perhaps a combo of both.

Windows has a subscribe-notify model (at least through .NET - I'm not clear if it's OS-level or .NET runtime level), so I'm kind of surprised that BSD doesn't. Heigh ho. Workaround city :wink:

Incidentally, how frequently does Hazel poll?

Hazel polls every few minutes (but also triggers for file events). 3.0 will use the newer fsevents model found in Leopard and later which will minimize, if not altogether, get rid of polling (it still might have to poll in certain circumstances).

The BSD advisory locks are fairly standard. At least it is for OS X which is all that matters in this case. It just comes down to whether the app developer uses it. Albeit, they may not know about it but I've found some devs to not be particularly responsive when I've filed bugs about it.

Mr_Noodle wrote:The BSD advisory locks are fairly standard. At least it is for OS X which is all that matters in this case. It just comes down to whether the app developer uses it. Albeit, they may not know about it but I've found some devs to not be particularly responsive when I've filed bugs about it.

Interesting. Mostly that it's not mandated by Apple's APIs. Well, thanks for the info and I look forward to new versions. You've already got a great app though. Thanks for creating it and supporting it so well!

To follow up on this thread, I've noticed the same problems when copying big video files to a Hazel folder. I've added a:
Date Lasted Modified not in the last 1 minute to avoid Hazel running on the file until it has finished copying but the problem still happens, and Hazel still marks the file as if it matches the rules, even though it doesn't. This probably happens because the metadata hasn't been written until the file copy is complete (it checks for duration. video codecs etc).

If I simply move the file into the folder (from the same drive), it doesn't mark the file incorrectly.

Any ideas on how to work around this?

Date last modified is not derived from Spotlight. There could an issue with buffering where it hasn't actually written out to disk. I suggest making the time more than 1 minute. Also, I suggest checking the logs to make sure what you think is happening is happening.