Receive now error messages on rules that worked before

Hello,

since a couple of weeks I receive now error messages on rules that never before had any problems.
For example I have a rule as follow:

When I look in the error log then it show this:

2024-12-03 06:26:44.920 hazelworker[1008] Error while matching rule Bilder against file /Users/..../Desktop/SendToKL.2023-1022_130525.zip: Could not retrieve metadata for file: /Users/..../Desktop/SendToKL.2023-1022_130525.zip

Another example is this here for a folder:

2024-12-01 01:18:41.003 hazelworker[1329] Error while matching rule Bilder against file /Users/.../Desktop/Schreibtisch - MacBook Air von Hans: Could not retrieve metadata for file: /Users/.../Desktop/Schreibtisch - MacBook Air von Hans

Can someone tell me where the problem is and what I can do against it? Not sure about it but think it came with the update Sequoia 15.1.1

It also only comes once, when I start or restart the computer.

Thank you
Hans

That indicates the file is not indexed by Spotlight. If you just upgraded, then there's a chance Spotlight is still rebuilding the index so you will need to wait a bit until it finishes.

Hello,

thank you for the hint. I reindexed everything and now it seems to work.
So thank you for your help.

Mr_Noodle wrote:That indicates the file is not indexed by Spotlight. If you just upgraded, then there's a chance Spotlight is still rebuilding the index so you will need to wait a bit until it finishes.

I was too fast saying that it worked.

I triggered the indexing again and also added the affected folder “Downloads” to the index with mdimport.
I also let macOS rebuild the index new.
However, I get an error message every time I start or restart the computer, which was not the case before. I just have the download folder monitored to move certain files after the download.
Of course I wonder why the problem is only occurring now and not before. Until recently I had no problems with the “Download” folder.

The metadata are correct:

And when I read the error message that's the problem hazel have with that file (example from many)

024-12-03 17:25:37.440 hazelworker[1208] Error while matching rule Music against file /Users/.../Downloads/Snagit.dmg: Could not retrieve metadata for file: /Users/.../Downloads/Snagit.dmg
2024-12-03 17:25:41.618 hazelworker[1208] [Error] Error during rule evaluation: Received error while trying to evaluate rule Music on file Snagit.dmg

Here the error message what popup:

Here the rule itself:

Apparently Hazel also seems to recognize that it is an image and not a music file.

If Finder is showing the wrong "Kind" then there is a deeper problem going on. Are you sure the indexing has completed?

Mr_Noodle wrote:If Finder is showing the wrong "Kind" then there is a deeper problem going on. Are you sure the indexing has completed?

Hello,

no the Kind is correct, because DMG is a disk image and not "Bild" = picture. The problem is that in Hazel everything is in English and my macOS is in German.
Sorry don't thought at that when I made the screenshot. The indexing is complete because when I use spotlight to search for the file it will be found and also show me the right location ('Downloads')
So everything from macOS perspective seems to work right.
As an example I show you the kind of a PNG picture:

If the error is only happening on startup, I'm wondering if it's an issue with Spotlight being a bit groggy and not being responsive.

I would not deny this statement, but then the question arises as to how to avoid Hazel starting to check the rules before the mdworker starts?
Apple may have changed the way Spotlight starts, but wouldn't it be up to the programmer to check whether Spotlight has already started to avoid such errors?
I know that there is a tool for Windows to delay the start of programs after logging on to the computer. Unfortunately, I
have not yet been able to find a tool to do the same on a Mac. So I have no possibility to delay the start of Hazel until all services are started safely.
The only thing you could do would be to remove Hazel from autostart and then start it manually, which would also be quite annoying.

I don't think there's been a general change but instead something about Spotlight on your specific system. What's odd is that I'm assuming this is not a new file so Spotlight should have indexed it long before. It seems as if something is clearing out its index for these files.

Hello,

today I was try to get the right date in a scanned document. When I did that (was on a network drive) I noticed also that here:

So nothing was deleted when I checked if the rule fit, but there was error message "metadata not found"
Based on this error, I would say that something is definitely wrong.
When I unmarked the file and marked it again everything was running fine and the test also showed me no "metadata" error anymore.
I assume that my Macbook with M1 processor and SSD is not necessarily (even if I don't want to rule it out 100%)
too slow to start all processes on time. What also speaks against it (nothing was installed additionally) is that Hazel worked perfectly until the update.
I'm not able to call Apple for that because I don't had a Apple care contract for this computer and the computer is out of the 1 year warranty.

That Error I only don't noticed because I'm not constantly checking the rules. Only if I notice that a rule is not working as expected.
So today I also figured out that the rules not only running on error while restart / start the computer.

If this is a network drive, that is a whole different issue. Depending on the protocol, the provider of the share, etc, there may be issues with Spotlight on that volume. For example, Synology's tend to not play well with Spotlight.

Hello,

What I have tried to do is to draw your attention to the fact that it is not just a local problem no matter how good Synology's SMB integration is.
Even if you copy the PDF file locally, it shows the same metadata as on the share.
Your tool for checking the rules also shows the correct metadata, but at the same time displays an error message that it cannot be read. See last screenshot.
How does this fit together?

I am just surprised that this error occurs locally as well as on the network.
I mean you can of course work around the error by turning off the notification, but that only shifts the problem, i.e. you don't see it every day that the error occurs, but the rules are then not executed correctly.

The second thing I think is that it is strange that everything worked until a special Apple update and then not. That alone speaks against an error in the system, especially if it concerns local and network filters.
I don't think you even have to be an IT expert to recognize that there is obviously a connection here.

I made now a workaround by deleting the files where I get the error message but that is not solving the Hazel problem at all.
If you plan in the future to investigate and solve the problem, I'm happy to support you with that.

You might want to find the errors in the logs and correlate that with certain system events. Is it only happen on reboot? Or when the file is just added? Both?

Mr_Noodle wrote:You might want to find the errors in the logs and correlate that with certain system events. Is it only happen on reboot? Or when the file is just added? Both?

As far as I could see only when I rebooted. The error on the network drive happened when I evaluated the rule.
I guess maybe it helps you if I send you the complete hazel log so that you maybe can look into?
It constantly like I saw today when I opened it again that error message like:

024-12-09 14:53:00.064 hazelworker[1377] File type not supported: {(
"com.noodlesoft.hazel.rules"

so the log file get big. each second hazel writes a line into.
Usually regarding a public.folder. But there are also other longer error messages which I do not want to publish here.

Also it looks since the new update Hazel has (HD Full access) not enough permissions to delete for example the trash:

Code: Select all: 2024-12-10 16:03:30.364 hazelworker[16413] Running worker (v6.0.3) for folder with identifier: trash. 2024-12-10 16:03:30.365 hazelworker[16413] ###Arch: arm64 2024-12-10 16:03:30.365 hazelworker[16413] ###main load address: 0x10008c000 2024-12-10 16:03:30.365 hazelworker[16413] ###Hazel Core load address: 0x10025c000 2024-12-10 16:03:30.365 hazelworker[16413] ###Noodle load address: 0x100554000 2024-12-10 16:03:30.365 hazelworker[16413] ###CK load address: 0x100144000 2024-12-10 16:03:30.363 hazelworker[16412] Running worker (v6.0.3) for folder with identifier: 16777231-235436. 2024-12-10 16:03:30.366 hazelworker[16412] ###Arch: arm64 2024-12-10 16:03:30.366 hazelworker[16412] ###main load address: 0x100b1c000 2024-12-10 16:03:30.366 hazelworker[16412] ###Hazel Core load address: 0x100cec000 2024-12-10 16:03:30.366 hazelworker[16412] ###Noodle load address: 0x100fe4000 2024-12-10 16:03:30.366 hazelworker[16412] ###CK load address: 0x100bd4000 2024-12-10 16:03:30.423 hazelworker[16412] Processing folder Downloads 2024-12-10 16:03:30.425 hazelworker[16413] Processing folder Trash 2024-12-10 16:03:31.520 hazelworker[16413] File Toolbox for Pages.app has been sitting in the trash for too long. Purging. 2024-12-10 16:03:31.520 hazelworker[16413] Removing Toolbox for Pages.app. 2024-12-10 16:03:31.522 hazelworker[16413] Could not remove Toolbox for Pages.app: Error Domain=NSCocoaErrorDomain Code=513 "“Toolbox for Pages” couldn’t be removed because you don’t have permission to access it." UserInfo={NSUserStringVariant=( Remove

So there is definitely something running the wrong way.
As said I would be happy to send you (if you let me know where) the complete logfile.

When I looked after my post the permissions I saw that there was a strange Hazel entry in the Permission list for the hard drive so I added manual Hazel to the full harddrive access list.