Hazel + 10.5.2 "Could not retrieve metadata"

Get help. Get answers. Let others lend you a hand.

Moderator: Mr_Noodle

Hazel + 10.5.2 "Could not retrieve metadata" Wed Feb 13, 2008 12:21 am • by Xipper
It seems that Hazel stopped working after applying 10.5.2, which is an essential fix for me.

I have tried to recreate some of my rules to see if that would help, but it seems there is something that Hazel relies on that must have been changed by 10.5.2:

hazelfolderwatch[1715] Caught exception in rule evaluation of file <file name>: Could not retrieve metadata for file: <full path to file>
Xipper
 
Posts: 9
Joined: Wed Feb 13, 2008 12:16 am

Wed Feb 13, 2008 2:48 pm • by Mr_Noodle
It depends. Usually that error is because Spotlight indexing is turned off for the drive/folder in question. Double-check your Spotlight settings (like if that folder is in the "Privacy" section). If you are commandline savvy, you can try the 'mdutil' command to see if indexing is turned on for that volume. You can also try running 'mdimport' to force indexing as I've sometimes seen certain directories not just be indexed for some reason.

Let me know if you find anything or need any more help with the above.
Mr_Noodle
Site Admin
 
Posts: 11226
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Feb 13, 2008 3:31 pm • by Xipper
I don't have any folders defined within the Spotlight privacy page on the internal drive. The folder in question is the Downloads folder for Safari, etc.

I performed a mdimport of the Downloads folder, it ran with no error. If I perform a Spotlight search, the contents of the Downloads folder are included.

Error:
2008-02-13 11:07:12.101 hazelfolderwatch[26459] Caught exception in rule evaluation of file WinSwitch3.2.1.dmg: Could not retrieve metadata for file: /Users/russel/Downloads/WinSwitch3.2.1.dmg

I find it odd that its happening on the main volume itself. I don't see anyway to control the MDS for that volume from the command line, as it doesn't show up in the output for checking status, etc.
Xipper
 
Posts: 9
Joined: Wed Feb 13, 2008 12:16 am

Wed Feb 13, 2008 3:52 pm • by Mr_Noodle
Is it only happening for that one file or are other files in that folder showing the same error?

Also, could you describe the rule(s) you are using? It may help to isolate things knowing which field is being matched against.

Thanks.
Mr_Noodle
Site Admin
 
Posts: 11226
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Feb 13, 2008 5:00 pm • by Xipper
It seems to be isolated to all folders/files within the Downloads folder.

Oddly, it seems to work on some occasions. I have tried downloading files using Firefox and Safari, both fail...but if i download a second copy of the same file with Firefox the 2nd copy gets the policy applied.

I am currently using the default "sample" rules applied to the Downloads folder.
Xipper
 
Posts: 9
Joined: Wed Feb 13, 2008 12:16 am

Wed Feb 13, 2008 5:10 pm • by Xipper
This may be resolved, it finally went through and marked all content as "new" (though it really isn't). I'll let you know if the other rules start to process completely.

Thanks for the help!
Xipper
 
Posts: 9
Joined: Wed Feb 13, 2008 12:16 am

Wed Feb 13, 2008 6:35 pm • by Mr_Noodle
Keep an eye on it and let me know if it pops up again. Another random question: was Spotlight doing a big scan of your drive at the time? Sometimes when Spotlight gets busy, it doesn't respond when asked for metadata.
Mr_Noodle
Site Admin
 
Posts: 11226
Joined: Sun Sep 03, 2006 1:30 am
Location: New York City

Wed Feb 13, 2008 8:20 pm • by Xipper
Thanks again. I haven't noticed Spotlight making any big scans, this error started showing in the log @ 2008-02-11 22:40:48.583

It was working prior to that, and seems to have corrected at 2008-02-13 12:59:31.143

Pretty strange, not sure if deleting the Download folder policies and recreating them resolved it or what...but I believe that was the last step I had made.

Thanks for the great product!
Xipper
 
Posts: 9
Joined: Wed Feb 13, 2008 12:16 am


Return to Support

cron