Indexing and Hazel

I’ve got an indexed folder which holds all my scanned but not yet renamed files. The folder is indexed so I can easily see related files to be able to rename the files faster and more consistently.

When I then rename the file to “YYYY_MM_DD Some Name” Hazel move the file into the enclosing folder (which isn’t indexed) and will then apply some tags and move the file into DEVONthinks Inbox folder from where the file is then imported.

While this works pretty good in theory about 30-50% of the time the renamed file (renamed inside of DEVONthink) will be moved to the systems Trash instead of the enclosing folder.
I cannot say what actually causes the files to be moved to the trash but it doesn’t happen when DEVONthink is closed and I haven’t noticed it when I rename files in the Finder directly.
My guess is that DT isn’t finished with renaming and Hazel already starts moving and this race condition leads to the file being trashed.

I don’t need the folder to be indexed but I need the “similar documents” suggestion from DT.
I also thought about migrating the tagging/renaming pipeline into DT but I don’t think its worth the effort since it works great with Hazel and I’ve spent a lot of time to get things right.

I just tested by running the rules manually and it is no race condition.
Even when waiting 10 seconds after renaming the file it may end up in the system Trash.

Which version of DEVONthink & macOS do you use?

I’m having a bit of trouble understanding exactly what you are doing with Hazel and DEVONthink. So I’ll explain what I do routinely and you can compare.

I have folder, not indexed in DEVONthink, which I collect things, e.g. scanned documents, incoming docouments, etc. Hazel “watches” this folder. I have some rules which attempt to rename based on content, e.g. bank statements which have consistent format and content. The file is renamed inside that folder. There is another Hazel rule which watches that folder looking for files with certain named format–in your case it would be looking for a valid date at the start. Upon finding such a file, Hazel moves the files into DEVONthink’s Global Inbox and from there DEVONthink takes care of the import. Inside DEVONthink I have a few rules which move it into the appropriate datebase/group.

What I’m uncertain about your process is you mention above moving the file after renaming to an “enclosing” folder. I’m not certain what you mean there. I don’t do any moving after rename. I think you could consider adding your tags with Hazel before the rename?

For what it’s worth, a while ago I wrote up my process: DEVONthink | Search Results | Musings on Interesting Things

Which version of DEVONthink & macOS do you use?

I use macOS 12.2.1 and DT Pro 3.8.3


Your process is quite similar to mine. Banking statements and other things which are consistently named will be tagged and renamed by Hazel and imported to DT.

The process I’m describing is for files without consistent naming (mostly scans). Those files have no meaningful name themself and I move them into the indexed folder. By moving them into an indexed folder I can use the AI of DT to show me similar files. So I can see how I’ve named the yearly invoice from my insurance in the past, copy the name and then only adjust the date.
When I then manually apply the naming those files will be moved to another folder and then tagged by Hazel and also imported to DT.

This all worked fine until I started to index the folder in DT in order to get those suggestions:
2022-03-28 13.11.01@2x

If there is an easier way to get those suggestions I’m happy to hear. Since indexing temporary files isn’t recommended.

A screenshot of your Hazel rule would be useful, thanks. Do you use any smart rules in DEVONthink that might have any impact?

Those are the two rules:



They both just match a pattern of either -YYMMDD or YYYY_MM_DD where DD and MM could be --. And then move it into the enclosing folder - from there Hazel will apply tags and in some cases rename the file.

I’m not sure if this rule could be the cause:


It would probably be safer to restrict “Item” to not be “Indexed”.

On its own this rule doesn’t seem to be a problem but currently this rule also matches indexed items and as it’s performed regularly (on startup, before sync) and not only after importing, adding the condition Item is not Indexed might indeed fix the issue.

I’ve disabled the rule for indexed files and will report if it still happens.
Thanks for support :slightly_smiling_face:


Unfortunately this didn’t fix the issue :frowning:

The issue also happened when I’ve renamed a file in Finder and DT was running.
I wasn’t able to reproduce the issue with DT closed.

What about triggering this rule only On Import? Does this make a difference?

It still happens.
Is this something which could happen due to the indexing?

Is there a way to get get similar file suggestions without indexing/importing?

This shouldn’t cause any issues. Does this still happen without your smart rule and/or manually renaming in the Finder without Hazel?

It did still happen with the rule disabled.
I don’t think anything will happen when Hazel is disabled.
I’ll try to specify the folder instead of using “enclosing folder” maybe this fixes it.

To be honest, I’ve sort of lost the plot on what your Hazel and DEVONthink rules are doing and what you are trying to do. It seems without thinking harder (and in a few days I’ll have some breathing space to think harder) it’s more complex than I do and I’m wondering about a few things.

I do notice and wonder if this has anything to do with anything, in your Hazel rule “Manually Renamed” you have an underscore at the beginning of the new file name. Deliberate?

I also wonder why after the Hazel rename rule instead of moving to the “enclosing folder” you move (or copy) then to the DEVONthink Inbox. I never used or as yet understand Hazel’s “enclosing folder”.

You mention you do tagging, but I don’t see any actions in Hazel and/or DEVONthink rules that does that. You can tag with Hazel actions.

I’d also check and confirm at the folder that Hazel is monitoring is indeed NOT indexed from DEVONthink as I don’t see any purpose to do so.

And I notice in your DEVONthink rule “Auto Move to Files Inbox” I wonder why you are doing that since Hazel will have already moved the file to the Inbox and DEVONthink at that point is reacting to it’s presence.

What I’m noticing and wondering about may not be spotting any problems/issues but just asking, as they say.

I try to do as much as possible to files in Hazel as it’s a tiny bit better at file manipulation than DEVONthink.

1 Like

This didn’t help either.
When I stop the Hazel rule nothing gets deleted but also nothing is moved.
So I need to further test without DT running if it happens then as well.

it’s more complex than I do and I’m wondering about a few things.

Yes, its been some time since I had a look at the full picture and probably could improve a few things.
But since it works well (apart from this issue) I didn’t allocate time to go over it.

I do notice and wonder if this has anything to do with anything, in your Hazel rule “Manually Renamed” you have an underscore at the beginning of the new file name. Deliberate?

All my files are named “YYYY_MM_DD Title”. If they are named “_YYMMDD Title” they’ll be renamed to “20YY_MM_DD Title” (as it is quicker to type). The rule matches for “-YYMMDD Title” since when I name a file in DT and the name starts with “_” the underscore will be omitted. (I’ll probably change it to always use “-” in the future…)

You mention you do tagging, but I don’t see any actions in Hazel and/or DEVONthink rules that does that. You can tag with Hazel actions.

The rules I mentioned here only apply naming. Those are applied to “~/Downloads/Scanned”. When the files are matched they’re renamed and moved to “~/Downloads” (enclosing folder) and there the tags will be applied. This is also the place where downloaded files like banking statements are matched.

I’d also check and confirm at the folder that Hazel is monitoring is indeed NOT indexed from DEVONthink as I don’t see any purpose to do so.

It is monitored since I sometimes rely on the related files from DT to rename the files.
See the graphic in this comment to see what I mean.

And I notice in your DEVONthink rule “Auto Move to Files Inbox” I wonder why you are doing that since Hazel will have already moved the file to the Inbox and DEVONthink at that point is reacting to it’s presence.

Previously I’ve been using AppleScript to add files to my DT inbox from Hazel directly. But I’ve got some errors back then when DT was not running and I just resorted to moving the files to the global inbox folder where DT will import the files on the next startup or immediately when running.
The DT Smart Rule is there to move the files from the global “Inbox” to the inbox of my “Files” database.

I try to do as much as possible to files in Hazel as it’s a tiny bit better at file manipulation than DEVONthink.

Me too. Since I’m using Hazel before DT had Smart Rules most of my automation was already in Hazel.

thanks. re above, “monitored” by Hazel but should probably (if no reason) “indexed” into DEVONthink. just check.

The issue appeared again and I found this in the Hazel log:

2022-06-07 21:16:19.824 hazelworker[2047] Running worker (v5.1.2) for folder with identifier: 16777232-898493.
2022-06-07 21:16:19.825 hazelworker[2048] ###main load address: 0x100a2c000
2022-06-07 21:16:19.825 hazelworker[2047] ###main load address: 0x1040fc000
2022-06-07 21:16:19.825 hazelworker[2048] ###Hazel Core load address: 0x100b60000
2022-06-07 21:16:19.826 hazelworker[2048] ###Noodle load address: 0x10101c000
2022-06-07 21:16:19.825 hazelworker[2047] ###Hazel Core load address: 0x104230000
2022-06-07 21:16:19.826 hazelworker[2048] ###CK load address: 0x100d90000
2022-06-07 21:16:19.826 hazelworker[2047] ###Noodle load address: 0x10464c000
2022-06-07 21:16:19.826 hazelworker[2047] ###CK load address: 0x104300000
2022-06-07 21:16:19.841 hazelworker[2047] Processing folder Downloads
2022-06-07 21:16:19.850 hazelworker[2048] Processing folder Scanned
2022-06-07 21:16:21.899 hazelworker[2048] File .DS_Store is busy. Skipping for now.
2022-06-07 21:16:21.904 hazelworker[2048] 2022_05_12 Strom Endabrechnung.pdf: Rule Copy Renamed matched.
2022-06-07 21:16:21.904 hazelworker[2048] [File Event] File moved: 2022_05_12 Strom Endabrechnung.pdf moved from folder /Users/jandamm/Downloads/Scanned to folder /Users/jandamm/Downloads.
2022-06-07 21:16:23.948 hazelworker[2048] File .DS_Store is busy. Skipping for now.
2022-06-07 21:16:24.128 hazelworker[2050] Running worker (v5.1.2) for folder with identifier: trash.
2022-06-07 21:16:24.130 hazelworker[2050] ###main load address: 0x1025b0000
2022-06-07 21:16:24.130 hazelworker[2050] ###Hazel Core load address: 0x1029b8000
2022-06-07 21:16:24.130 hazelworker[2050] ###Noodle load address: 0x102810000
2022-06-07 21:16:24.130 hazelworker[2050] ###CK load address: 0x1025e4000
2022-06-07 21:16:24.141 hazelworker[2050] Processing folder Trash
2022-06-07 21:16:25.248 hazelworker[2050] Received error while processing file /Users/jandamm/.Trash: Error Domain=NSCocoaErrorDomain Code=257 "The file “Trash” couldn’t be opened because you don’t have permission to view it." UserInfo={NSURL=file:///Users/jandamm/.Trash, NSFilePath=/Users/jandamm/.Trash, NSUnderlyingError=0x600001ebbc90 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
2022-06-07 21:16:25.249 hazelworker[2050] Error traversing path during sizing operation file:///Users/jandamm/.Trash: Error Domain=NSCocoaErrorDomain Code=257 "The file “Trash” couldn’t be opened because you don’t have permission to view it." UserInfo={NSURL=file:///Users/jandamm/.Trash, NSFilePath=/Users/jandamm/.Trash, NSUnderlyingError=0x600001eb9e30 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}

It seems it is moved to Downloads and then directly to the Trash afterwards :man_shrugging:

I checked the Console and I found this line between the check of Scanned and Downloads.

default	21:46:02.879379+0200	DEVONthink 3	Write options: 1 -- URL: <private> -- purposeID: 924444BE-1FAF-45D0-B99E-CDAB3C099E6B -- claimID: F91E35CF-7C1E-4278-9EB6-BD971F54339D
1 Like