Acting on items inside aliased folders

Can Hazel do actions on aliased folders? I'm running the 'Run rules on folder contents' action and get matched results according to the Previewed Rule Matches. But it looks like subsequent actions on the items inside the aliased folders are ignored. I'm trying to detect if the folders have files added to them, and if they don't Hazel should run a quit app action. Probably a case of a misformatted rule. If Any file Date Added not in last 15 minutes then run workflow quit app. Any ideas?

Hazel will not follow aliases by design. Hazel operates on the alias files themselves. To get Hazel to process these folders, you need to add the actual folder the alias is pointing to itself.

I've considered having Hazel follow aliases but it opens things up to all sorts of problems. In some cases, people create loops which can cause havoc or someone unpacks some software which has an alias to their Applications folder (devs often do this to make it easy to install the software). This would bog things down if Hazel does a full walk of the whole file tree.

The Preview function is broken in this regard and will misleadingly report a match as a folder. That part should be fixed in the next release. Sorry about that.

Mr_Noodle wrote:In some cases, people create loops which can cause havoc or someone unpacks some software which has an alias to their Applications folder (devs often do this to make it easy to install the software).

It's off-topic, but that reminded me of something I've been wondering for awhile:

Is anyone aware of vulnerabilities that might be exploited with an Applications alias like that actually referencing some folder other than /Applications?

Theoretically, you could have the alias point to somewhere else and have the program replace some standard one but access permissions (if set up properly) should prevent overwriting something critical without asking for a password.

Note that running the application from anywhere runs the attacker's code (if the app is some sort of malware). There may be rare cases where the location of the app matters for an attack but in general, the vulnerability is in the code execution and less so about the location.

In any case, this is off topic for this thread so start a new thread (though try and give it some relevance to Hazel).

Maybe you could add the alias resolve feature as some sort of advanced preference or option, with a warning about using it?

I am using Hazel to auto-generate aliases of recently modified folders, so there's no way to set specific rules for these. However I would like to be able to just run Hazel rules on these (resolved) aliases. A nice way to get "temporary" rules.

These are folders whose originals are in a "master" location and all the folders' contents in the "master" location do not need the rules applied, so running a "subfolder depth is…" rule condition isn't feasible. I just want to run the rules on the contents of the folders who qualified for the creation of the aliases.

…although I suppose I could just add another action to the folders who meet the "make alias" criteria. That might be a better solution for my particular situation.

Wouldn't help for existing aliases.

Could you maybe draw/map this out as I'm not understanding what you are trying to do here. Thanks.

I have a folder which contains many folders, some of which get updated as specific files get downloaded to them. I recently created a rule that creates aliases (inside a different folder on the desktop) of any folders which get updated so I can instantly see which ones have new files, and also have instant access to the contents.

What i was trying to do with the resolved aliases was then process (unarchive) the archives within the aliased folders. But as I mentioned, I could just do this as part of the 'make alias' rule since these aliases are generated by Hazel.

However if one enter to do this with existing aliases, it wouldn't work.

I'm not sure even if Hazel creates the alias that that would work. Hazel would still treat the target of the rule as the alias file and will not resolve it. If you are seeing otherwise then I'm not sure how that is working.

Can't you just process the original folders instead? Again, maybe I'm missing something here.

Mr_Noodle wrote:I'm not sure even if Hazel creates the alias that that would work. Hazel would still treat the target of the rule as the alias file and will not resolve it. If you are seeing otherwise then I'm not sure how that is working.

Can't you just process the original folders instead? Again, maybe I'm missing something here.

As I mentioned above, just processing these folder content as the aliases are created by Hazel works fine. But for existing aliases, no go. But not a problem.

Sometimes the toughest thing about Hazel is just figuring out the logic chain.

It's still not making sense to me so it's hard for me to help you on this. Hazel does not follow aliases so I don't see how it makes a difference whether Hazel created it or they already existed.

I did take your suggestion and process the original folders with the rule for which I had Hazel create aliases. So that is taken care of.

And I understand that Hazel does not drill into an alias, so there's no confusion there. I just use aliases that were not created by Hazel, and originally wanted to be able to have Hazel process those folders, but like i said I understand that this is not possible.

Sorry for any confusion.