No metadata found

Last edited by flynn on Sat Apr 21, 2012 7:49 am, edited 2 times in total.

I have recently changed MacBooks, and all my files were saved on dropbox.
On my old macbook, the rules worked perfectly fined. They sync a file from dropbox into iCloud when the file is changed. I exported my rules and got all my files back with dropbox, and since then the rules keep giving me an error saying that they could not be evaluated. When I go into the hazel pref, all my files say they have no metadata available. How is that possible? How can I fix it? Please help

I tried reading the logs, but they say something either like "no rule could be match" or they tried to compare a .ppt file with my pages rule for example, and return an error in that case also.

BTW, I can see your screenshots.

If it says there is no metadata you need to look at your Spotlight configuration. Check your Spotlight preferences and make sure the folder in question is not covered by the Privacy settings.

If things check out there, then you need to use the 'mdutil' commandline tool to check indexing on that drive in question and maybe manually re-generate the metadata using 'mdimport'. I don't know of a GUI tool to do this off-hand but if you aren't commandline savvy, then you may want to google around for something.

Mr_Noodle wrote:BTW, I can see your screenshots.

Can or can't?

They don't display inline here but, with Safari, I can right-click on a broken image icon and select Open Image in New (Window|Tab) to see the full image.

Whoops, meant "can't". But yes, clicking one them does work. Thanks.

sorry for the images, I'm not exactly sure why they don't show up. I'll edit later.
I checked spotlight preferences, nothing is made private and all the checkboxes are checked in the search result.

I have found that if I change the file in any way, it then works correctly with hazel. But I can't go around and change 250 files one by one.

Can you please elaborate on the command lines?

I tried mdutil -p, -s, -v, -E, and none of them seem to do anything.

I found that mdls returns the metadata for a particular file, and this is the typical info return for most of my files:

kMDItemAlternateNames = (
"Columbus reading questions.doc"
)
kMDItemContentCreationDate = 2012-03-02 15:54:20 +0000
kMDItemContentModificationDate = 2012-03-02 15:54:20 +0000
kMDItemContentType = "com.microsoft.word.doc"
kMDItemContentTypeTree = (
"com.microsoft.word.doc",
"public.data",
"public.item"
)
kMDItemDateAdded = 2012-04-21 08:05:52 +0000
kMDItemDisplayName = "Columbus reading questions"
kMDItemFinderComment = "pages"
kMDItemFSContentChangeDate = 2012-03-02 15:54:20 +0000
kMDItemFSCreationDate = 2012-03-02 15:54:20 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 16
kMDItemFSHasCustomIcon = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 1
kMDItemFSIsStationery = 0
kMDItemFSLabel = 0
kMDItemFSName = "Columbus reading questions.doc"
kMDItemFSNodeCount = 19230
kMDItemFSOwnerGroupID = 20
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 19230
kMDItemFSTypeCode = ""
kMDItemKind = "Microsoft Word 97 - 2004 document"
kMDItemLogicalSize = 19230
kMDItemPhysicalSize = 24576

Looking at it again, are there other rules in play here? That one rule you posted doesn't access the Spotlight metadata so I think there might be something else that is the problem here.

there is one other rule, and it does the exact same thing as this one, but with .doc, .docx, and .pages.

ahhhh I found my problem, though it the metadata error doesn't make sense: My condition was comparing last modified is after last checked, when it was supposed to read before. I also used an extra rule to exclude all items that do not have the extensions .pages .doc .docx .key .ppt .pptx, and it works again. I think you might need to check that rule's errors

Just to be clear, you want to match files which have NOT been modified since last time? If that's what you want then fine though I just wanted to check since it's usually the other way around.

No I don't, that was my mistake. I changed that to match files which had been modified and all the metadata errors disappeared. What I'm not sure is how the other case could return a metadata error.

That's odd. I don't see changing that rule from one direction to the other would change whether or not it access the Spotlight metadata. Perhaps the file got indexed in between tries so it had the data later? If it pops up again, let me know.

after updating to Hazel 3.0.7, i'm getting lots and lots of "There is no metadata available for the file" errors. Hazel actually throws errors when it tries to run rules on these files — rules which haven't been altered at all since before the update. i recently implemented some rules to clean up my ~/Music folder, which had been working great, but since it looks at the entire folder contents, i got about 2000 Growl errors. i had to stop Hazel and turn off Growl to settle things down.

a restart hasn't helped either. i know that Mr. Noodle sometimes advocates doing an uninstall and reinstall for fixing wonky problems like this. i'm just concerned whether doing so will reset Date Last Matched data. if it does, a bunch of my rules will run rampant, applying actions to files that they shouldn't.

oh, and here's an example of one of the errors from Hazel.log:

Code: Select all: 2012-06-01 13:09:49.983 hazelworker[5743] [Error] Error during rule evaluation: Received error while trying to evaluate rule replace underscores in filenames on file Carry On.m4a 2012-06-01 13:09:49.985 hazelworker[5743] Error while matching rule replace underscores in filenames against file /Users/ed/Music/fun./Some Nights/Carry On.m4a: -[__NSCFString timeIntervalSinceReferenceDate]: unrecognized selector sent to instance 0x1002660e0 2012-06-01 13:09:49.986 hazelworker[5743] ( 0 CoreFoundation 0x00007fff9020ff56 __exceptionPreprocess + 198 1 libobjc.A.dylib 0x00007fff9329ad5e objc_exception_throw + 43 2 CoreFoundation 0x00007fff9029c1be -[NSObject doesNotRecognizeSelector:] + 190 3 CoreFoundation 0x00007fff901fce23 ___forwarding___ + 371 4 CoreFoundation 0x00007fff901fcc38 _CF_forwarding_prep_0 + 232 5 CoreFoundation 0x00007fff901dd0eb -[NSDate compare:] + 59 6 hazelworker 0x0000000100023cbe start + 139858 7 Foundation 0x00007fff929cae05 -[NSComparisonPredicateOperator performPrimitiveOperationUsingObject:andObject:] + 400 8 Foundation 0x00007fff929ca701 -[NSPredicateOperator performOperationUsingObject:andObject:] + 109 9 Foundation 0x00007fff929c9fe8 -[NSComparisonPredicate evaluateWithObject:substitutionVariables:] + 290 10 Foundation 0x00007fff929c9a9a -[NSPredicate evaluateWithObject:] + 18 11 hazelworker 0x00000001000380c0 start + 222804 12 hazelworker 0x0000000100037dc5 start + 222041 13 hazelworker 0x000000010003d13e start + 243410 14 hazelworker 0x0000000100037670 start + 220164 15 hazelworker 0x0000000100002c5e start + 4594 16 hazelworker 0x0000000100003b74 start + 8456 17 hazelworker 0x0000000100006a9c start + 20528 18 hazelworker 0x0000000100001aa0 start + 52 )

Note that Hazel's preview incorrectly reports the error in this case. In this case it has nothing to do with metadta. Open the rule in question (the log notes which one) and save it again. That should clear it up.

I have exactly the same problem since a day or so (well AFTER upgrade to 3.0.7) with most of my rules, on Dropbox, Desktop and so on. When just looking at rules, there is this orange exclamation mark which shows "There is no metadata available for the file.", and when executing, growl reports thousands of errors which look in the log like

2012-06-04 06:04:26.158 hazelworker[11581] [Error] Error during rule evaluation: Received error while trying to evaluate rule folder or some subfile open or modified last hour on file Bamboo Paper
2012-06-04 06:04:26.158 hazelworker[11581] Error while matching rule folder or some subfile open or modified last hour against file /Users/hansen/Dropbox/Bamboo Paper: -[__NSCFString timeIntervalSinceReferenceDate]: unrecognized selector sent to instance 0x100603f70
2012-06-04 06:04:26.158 hazelworker[11581] (
0 CoreFoundation 0x00007fff8edf0f56 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8b47ad5e objc_exception_throw + 43
2 CoreFoundation 0x00007fff8ee7d1be -[NSObject doesNotRecognizeSelector:] + 190
3 CoreFoundation 0x00007fff8eddde23 ___forwarding___ + 371
4 CoreFoundation 0x00007fff8edddc38 _CF_forwarding_prep_0 + 232
5 CoreFoundation 0x00007fff8edbe0eb -[NSDate compare:] + 59
6 hazelworker 0x0000000100023cbe start + 139858
7 Foundation 0x00007fff859ede05 -[NSComparisonPredicateOperator performPrimitiveOperationUsingObject:andObject:] + 400
8 Foundation 0x00007fff859ed701 -[NSPredicateOperator performOperationUsingObject:andObject:] + 109
9 Foundation 0x00007fff859ecfe8 -[NSComparisonPredicate evaluateWithObject:substitutionVariables:] + 290
10 Foundation 0x00007fff859eca9a -[NSPredicate evaluateWithObject:] + 18
11 hazelworker 0x00000001000380c0 start + 222804
12 hazelworker 0x0000000100037dc5 start + 222041
13 hazelworker 0x0000000100037dc5 start + 222041
14 hazelworker 0x0000000100037dc5 start + 222041
15 hazelworker 0x000000010003d13e start + 243410
16 hazelworker 0x0000000100037670 start + 220164
17 hazelworker 0x0000000100002c5e start + 4594
18 hazelworker 0x0000000100003b74 start + 8456
19 hazelworker 0x0000000100006a9c start + 20528
20 hazelworker 0x0000000100001aa0 start + 52
21 ??? 0x0000000000000002 0x0 + 2
)

So, is it the metadata thing, or something else (and if I have to repair the metadata, how?)

I must say, that as it stands, hazel is definitely NOT working anymore ...

Thanks!

Thomas