Noodlesoft Forums

Hazel’s behaving in a way I’ve never seen before.

It’s renaming files for me, based on a date in the file (when a receipt was emailed). The odd thing, though, is that it’s using “08” as the month, even when it should be “06” or “07”.

It’s getting the year (so far they’re all 2020 files, so this may not mean much) and the day correct.

So a file internally dated “2020-06-27” in one instance and “Jun. 27, 2020” in its second, is getting renamed “2020-08-27” (when I’m expecting “2020-06-27”).

Strange? Anyone else seen anything like this before? The files in question are email messages printed to PDF (from Mailmate), and the only odd thing I can think of is that in some cases, the first date — the date header in the email — is offset by a day as compared to the date on the receipt. None of these file-dates straddle the end of one month and the beginning of the next.

This isn’t a new Hazel rule, either, though I hadn’t invoked it in ages; it’s possible it was always borked and I just failed to notice, but I don’t think so?

Hazel 4.4.5 (build 1576); macOS 10.15.6.

Can you post/email in the rule?

Mr_Noodle wrote:Can you post/email in the rule?

Are those screenshots helpful/sufficient, or would you like to see something more?

In my experience Hazel sometimes has a problem seeing a date that is too close to the top of a page. Try not considering an occurrence at the top of the page when counting...or set the count from the end of the file.

I setup your rule to act on one of my old Apple Subscription Confirmations and it would not get the email date at the top of the page.

EdBurke wrote:In my experience Hazel sometimes has a problem seeing a date that is too close to the top of a page...

Great idea! Thanks — I’ll try that.

EdBurke wrote:…set the count from the end of the file…

Worth a shot; an item filed with today’s date (internally) got correctly renamed “2020-08-03”, but one from July 3rd also came out as “2020-08-03”.

So weird.

I tried your rule again this morning and realized the date of the month format you're using in the date match could be causing the problem. 31 is looking for a leading zero...try changing the date format to 31. Using 31 in the date match returned erroneous results for me.

By the way, Hazel is able to see the date at the top of the page in the emails I have used for debugging.

If the above suggestion doesn't work, an outline of your workflow might be of value...including the email client you're using.

Also, I suggest using the preview features. That will highlight the text in the document that it's matching.

Mr_Noodle wrote:Also, I suggest using the preview features. That will highlight the text in the document that it's matching.

I feel like I’m missing something important, here.

I’ve been using preview to see which individual conditions of any given rule pass or fail: Red  ×  or green √.

Are you saying there’s a way to visually preview the text matches (or lack thereof) for “Contents contain xyz” conditions within a target file?!?

Click the red X or green checkmark.

Mr_Noodle wrote:Click the red X or green checkmark.

O M G

Mind: blown.

How did I never think to try this?

Thanks!