UPDATE: This seems to be an iCloud issue and not a DEVONthink issue, although it does cause particular problems for me in DEVONthink, since the changed syntax causes nesting of tags in DEVONthink.
I’m not sure how it’s happening, but in DEVONthink, all the tags that I’ve been using for years (following advice from Brett Terpstra) with the formal “tag:subtag” have been converted in my indexed databases into nested tags, and in Finder, they appear as “tag/subtag”. I’m having a terrible time trying to reverse this: renaming the “tag/subtag” format to “tag:subtag” in Finder, but they keep coming back as zombies.
I’d appreciate any ideas for how to troubleshoot this. Thanks!
Screen captures would be useful. We can’t see your screen all the way over here 
Fair enough! It’s taken some time to make the screenshots, because DEVONthink is beach-balling something fierce on my MacMiniM2. (Happens a lot, which is part of why I’ve been trying to sort out whether the tags are what is slowing me down and demanding so much RAM.).
The problem started with seeing that tags have been changed (I think by DT) from “prj:electoraltech” to “prj/electoral”:
In DT, this shows up as nested tags, “prj” and “electoraltech”. This is not my intention. For all the reasons you’ve given, I’ve decided not to use nested tags.
In the following screen recording, you can see how, in Finder, I try to assign the original “prj:electoraltech”, but it keeps getting overridden in Finder with “prj/electoraltech”. Even if I first remove “prj/electoral”.
Here is a screen recording: SURFdrive
Back in DT, this is a screen shot that shows the tags. It still has the separate “prj” and “electoraltech” tags (created when the “prj/electoraltech” and nesting was introduced), but it does show the “prj:electoraltech” tag, although that is missing in Finder!
Here you can see, in Finder, there is a “prj:electoraltech” tag, but it doesn’t show the “Amoah 2020” file, so apparently that format of the tag is not assigned.
And here you can see that file shows up in Finder, when I select “prj/electoraltech”:
I hope this gives you a better view of what’s going on. I’m baffled.
What version of macOS are you running?
macOS 14.4.1 (23E224); Mac mini M2
See comment #6 by PSA. I couldn’t find more detail on this, though.
1 Like
By the way, while I was away from my computer, the tag “prj:electoraltech” has now disappeared.
This file is in an indexed database, syncing (non-legacy) with iCloudkit.
@chrillek Thanks for that link. I’ve tended to trust Brett Terpstra’s advice on this, and he’s been using tag:subtag syntax for a long time – and he works his machine hard. But I’m not sure he’s using DT.
It would be unfortunate to give up the possibility of searching for parts of a tag string, as in searching for “subtag” and finding files with “tag:subtag”. But maybe the problem is with the syntax the the : (colon)?
The DT database is indexed to a folder on my MacMini that is in iCloud.
The DT database syncs with my MacBook Pro (M1). On my MBP (which has been shut down and turned off all day), it’s the same set up: the database there is indexed to a folder on my harddrive, which syncs with iCloud.
My understanding is that this is pretty standard setup.
Have you tested this with a non-iCloud folder?
Please clarify … you have an files in iCloud that are indexed into your DEVONthink database which resides on the local drive outside of iCloud, or is the DEVONthink database stored in iCloud?
Good idea. That seems stable. I’ll try moved the folder into iCloud, and see what happens.
All my DT databases are always stored in folders that are not synced (except via DEVONthink iCloud (CloudKit) service. But the contents of the databases are files that are stored in folders that do sync via iCloud.
1 Like
Bingo! After moving the folder to an iCloud folder and indexing that folder (10 files or so), the “tag:subtag” syntax generated nested tags in DEVONthink, and now all the tags in Finder for the indexed files have the syntax “tag/subtag”.
Interesting and unsurprising, though I can’t explain the specific mechanism. Even Apple is inconsistent in their filesystem behaviors.
Perhaps development may have some thoughts on this.
May I ask your purpose in storing the files in iCloud? Is it for mobile access?
My question is: Why is DEVONthink converting the tag1:tag2 format into nested tags? And why does it happen with some but not all such tag-combinations?
May I ask your purpose in storing the files in iCloud? Is it for mobile access?
No, I tend to find that DTTG is best for accessing working files from my iPad or iPhone. The reason for storing files in iCloud is different: I believe you advised me (and others) early on not to view DT as a “Finder replacement”. So, I have a 2TB of iCloud storage, and I use that to make sure that my Macbook mirrors my desktop mini. I use DT for working with large projects, such as my library of journal articles in PDF, or all my university teaching materials. But almost all of them (except for cold storage) are indexed and not imported.
It’s possible the tag registered as tag:tag then was somehow modified in iCloud Drive.
colons are the reserved characters for Apple’s non-UNIX filesystem paths, e.g., Macintosh HD:Users:Godzilla:Desktop so a conversion to a slash isn’t entirely unexpected. The odd bit, and this is also an Apple oddity, the forward slash is the reserved delimiter for paths in the underlying UNIX 
I believe you advised me (and others) early on not to view DT as a “Finder replacement”.
Indeed, this is true. It’s not meant as a general file manager.
So, I have a 2TB of iCloud storage, and I use that to make sure that my Macbook mirrors my desktop mini. I use DT for working with large projects, such as my library of journal articles in PDF, or all my university teaching materials. But almost all of them (except for cold storage) are indexed and not imported.
Okay, but are you keeping them local to the Mac, i.e., not only storing them in iCloud online? You should be indexing local resources.
But tags have nothing to do with file system paths. They’re just strings in an array that’s stored as part of the extended attributes. I don’t see a technical rain to replace colons in tags. Much less, as you noticed, with the Unix path separator.
