Trouble with unarchiving & file types

I'm having trouble with Hazel being a little too aggressive in unarchiving files:

I have Hazel set to monitor my Downloads folder and unarchive things that appear to be archives. So far, so good. I have zip files that contain Procreate brush sets (which are, themselves, special types of archive) with the extension .brushset. Unfortunately, Hazel unzips the archives and then tries to unarchive the brushsets, which results in a folder full of broken files that won't work in Procreate. I need Hazel to unarchive the zip but then stop if it encounters a resulting .brushset file. I've added a condition to my "Unarchive Downloads" rule: IF "Extension" IS NOT ".brushset" to continue unarchiving/matching rules as usual. It seems to be ignoring that condition, though- I keep getting folders full of broken brushsets. If I save the brushset zip to the Desktop and double-click it, it unarchives (using my default app BetterZip which I have set to ignore .brushset files). My questions are:

1. Is Hazel using it's own unarchiving software or does it use the system default app for unarchiving?
2. Is there some reason it would ignore conditions that would check the extension after unarchiving the zip files?
3. Am I doing something else wrong?

Please go through the troubleshooting guide here: https://www.noodlesoft.com/kb/hazel-tro ... ing-guide/

Also, can you run the 'mdls' command on the file in Terminal and send me the output? My guess is that Procreate is miscategorizing, or under-categorizing the brushset files. Many file formats are actually zip files but if the program doesn't do anything to distinguish it from a zip file, then Hazel won't be able to tell the difference. For instance, MS Office does this for its files but does add additional categorizations to indicates it is more than a zip file.

Hey there- running mdls on this brushset gives me this:

_kMDItemDisplayNameWithExtensions = "MORT.brushset"
kMDItemContentCreationDate = 2021-12-07 10:20:32 +0000
kMDItemContentCreationDate_Ranking = 2024-06-12 00:00:00 +0000
kMDItemContentModificationDate = 2021-12-07 10:20:32 +0000
kMDItemContentType = "dyn.ah62d4rv4ge80e6xzsryhg3py"
kMDItemContentTypeTree = (
"public.item",
"dyn.ah62d4rv4ge80e6xzsryhg3py",
"public.data"
)
kMDItemDateAdded = 2024-06-12 19:49:10 +0000
kMDItemDisplayName = "MORT.brushset"
kMDItemDocumentIdentifier = 0
kMDItemFSContentChangeDate = 2021-12-07 10:20:32 +0000
kMDItemFSCreationDate = 2021-12-07 10:20:32 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = (null)
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = (null)
kMDItemFSLabel = 0
kMDItemFSName = "MORT.brushset"
kMDItemFSNodeCount = (null)
kMDItemFSOwnerGroupID = 20
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 5028638
kMDItemFSTypeCode = ""
kMDItemInterestingDate_Ranking = 2021-12-07 00:00:00 +0000
kMDItemKind = "Prospect Document"
kMDItemLogicalSize = 5028638
kMDItemPhysicalSize = 5029888

...the one thing that makes me pause is the "kMDItemKind = "Prospect Document"" near the end. Prospect is an app that basically lets you QuickLook brushsets: https://jaromvogel.com/prospectapp

I wonder if that might be interfering with Hazel somehow? It seems like Hazel should still at least be recognizing the ".brushset" extension and stop the workflow.

Actually, it occurred to me that Procreate is not a Mac app. The categorization that is there is basically no categorization. You need an app that handles brushsets and categorizes them properly.

That said, again you need to go through the troubleshooting guide. Filtering on the extension should work so I suspect something else is going on.

So I paused Hazel and dragged both an unarchived .brushset file and the zip containing a .brushset file into the Downloads folder, and then did a Preview Rule on both files. Observations:

1. the .brushset file comes back as NOT matching as an archive. It does correctly detect and match the .brushset extension, however.

2. the zip file correctly comes back as matching as an archive, and also gets the correct extension.

3. Hazel DOESN'T try to unarchive the standalone .brushset file- it only does that when it's inside a zip file, so it MUST be correctly getting the extension right on the file itself.

Unrelated, maybe:
4. even while paused, Hazel continues to run rules and immediately unzips the zip file and the .brushset file, resulting in a folder full of broken brushes. I have to uncheck the "Downloads" rule to keep it from running that rule.

Ah, so that's a key detail. If the brushset file is inside a zip, then it will trigger the unarchive process. Once in that process, it will try and unarchive as long as it keeps finding archives. At this point, your rule conditions don't apply here as it's already trying to unpack everything. I suspect the brushset file is an archive format underneath. Again, without proper categorization, Hazel cannot know that this file is not meant to be unpacked.

I suggest using the "Open" action on the zip file instead. That will use the system's unarchiver which will only unpack the outer layer.

Mr_Noodle wrote:Ah, so that's a key detail. If the brushset file is inside a zip, then it will trigger the unarchive process. Once in that process, it will try and unarchive as long as it keeps finding archives. At this point, your rule conditions don't apply here as it's already trying to unpack everything. I suspect the brushset file is an archive format underneath. Again, without proper categorization, Hazel cannot know that this file is not meant to be unpacked.

I suggest using the "Open" action on the zip file instead. That will use the system's unarchiver which will only unpack the outer layer.

Aha! That definitely worked, although I needed to then add a "If Kind is not 'Disk Image'" statement to keep it from also opening any .dmg files in my Downloads folder. It's leaving the .brushset file alone now. Thanks! It's unlikely the proper categorization will ever get added to the brushset files unless Procreate somehow decides to make a Mac app so this is a good workaround.