Serious problem with tag functionality since 2.0 release

DEVONthink Tips
1

Hi all,

I’ve been using DTPO for a little less than a year now and have spent a long time transferring my old group structure over to tags because I found the option to add tags directly while viewing files more intuitive and user-friendly than replicating / duplicating to various groups.

However, since upgrading to the full release a week and a half ago, I have observed a VERY strange and dangerous behaviour with tags and have just lost a number of files from my database (all of which are backed-up, thankfully) as a result.

My workflow basically involves a lot of marking up PDFs in Skim, from which I export notes as an RTF back into my DTPO database for tagging and storage. I had grown comfortable with importing notes as RTFs and tagging them directly using the Tags bar. I particularly liked the fact that if no appropriate tag existed, I could simply type the name of a new tag, hit Enter and viola - a new tag was created. I also liked the automatic addition of parent tags to a file, so that hierarchised tagging structures became very useful to me. I have been eagerly awaiting the full release to regain access to the AI features in DTPO while sticking with the tagging system I am now comfortable with.

Now, since upgrading to the full version, the actual tagging behaviour functions in exactly the same way (i.e. I can add existing tags or new tags while viewing a file directly). However, any attempt to move a new tag into a parent tag now replicates the tag, leaving the original in the root tag structure. This would still be acceptable for my workflow, as I could then simply delete the original tag, but this is where the dangerous part comes in…

If a single instance of a tag is moved to the trash (e.g. the original tag in the example above), this does not alter other instances of the same tag, or the file to which the tag is attached. So the original tag disappears, leaving the replicated tag in its new folder. But when the trash is emptied, not only does the instance of the tag moved to the trash disappear, but so do any other instances of this tag.

Not only this, but so does every instance of the file the tag has been applied to!!!

To give another example of how this presents a serious problem, I had set up a tag folder for a particular project I had been working on. Previous to the final release, at the end of the project I could simply delete the tag, leaving the files in my database (all of which were tagged with other topic-related tags as well). Now, if I follow the same procedure, every single file tagged with the tag I am deleting is deleted along with it, but only at the point when I come to empty the trash, i.e. at the precise moment when the option to undo is removed.

I’m sorry if this post is overly long and my tone overly irritated, but I simply cannot see any logic whatsoever to the new tagging functionality in the final release. I can’t see any use for tags at all in this version and will have to transfer all my current tags back to my group structure to avoid any further disasters. I had been so looking forward to being able to combine the ease of tagging with the AI features (the original reason for my moving not just to DTPO but to Mac overall)!

For the moment, it looks as though I’m going to have to jump into my Time Machine and check how many of my files I might have inadvertently lost in the last week and a half and completely restructure my database into groups.

Dan

2

Thank you for your very important post. It prompted experimentation over here and I can confirm all of your findings (except I can’t yet make the original tagged document go away as you described).

It appears that a contributing cause is that DT is treating tags dragged from one level of the Tags group to another (i.e., sub-tags) as replicants of the first instance of the tag. But these are bizarro replicants - they don’t behave like normal replicants. At a minimum, I observed these undesirable effects:

First, If any tag-replicant in Tags is deleted, the other tag-replicants in Tags are converted to normal groups (i.e., no longer tags) - normal replicants don’t act that way. Bizarro replicants do.

Second, when the trash is emptied, the former-tags-now-groups that are left behind in Tags are zapped. (They never appear in the trash.)

(Annoying work around to #2 - drag a former-tag-now-group out of Tags and into the regular hierarchy, empty the trash, put the former-tag-now-group back into Tags, and it becomes a reborn tag, no longer a bizarro tag.)

I don’t see why copies of tags are replicants (or duplicates) for that matter. DTPO should treat tags that are dragged into other tags in Tags as independent objects. Their content (the tagged records) shouldn’t change when the original tag changes, their deletion shouldn’t affect the orignal tag, etc.

I understand (grudingly) the tags-are-groups approach. The other behaviours surely cannot be intended?

3

i actually think that they introduced a serious bug when introducing tags.
i occasionally find items in a group that has nothing to do whatsoever with the group. this happens every time i open a group with a name that is redundant in my group list. for example: books.
groups:
machine learning - math - books
programming - cryptography - books
tags:
machine learning - data mining - general application => here i have a few pdfs that i manually tagged with the tag ‘books’.

and this causes problems. those manually tagged ones will show up in some groups named books. but randomly.
i just imported a book named ‘Mining Graph Data’, added the tag ‘books’ and dragged it to ML - DM - GA. it shows up there, but also in programming - cryptography - books. it doesn’t show up in ML - math - books.

i don’t understand that behavior at all, if that is the behavior they want, i will stop using DT.

and one thing i just noticed too:
the auto-classify doesn’t work properly either, it is a real gamble where DT is going to add a file. but maybe my database is too small (126 groups, roughly 3GB, 800 PDFs/200 webarchives, 30M total words/800k unique words)

4

Hi Korm,

Thanks for your post - the work-around you proposed does indeed seem to avoid any unintended deletions, but unfortunately it also severely negates the ease-of-use factor which had led me to move to tagging in the first place!

That’s strange that your tagged files didn’t disappear along with your tags, I’ve tried to repeat my disaster and had no problems doing so.

As you point out, it’s not the replicant functionality that’s the problem, it’s the bizarro replicant functionality. If tags simply acted like replicant groups, but with the added function of direct addition / creation and hierarchisation, I’d be happier. Although as you say, tags really should simply act completely independently of each other, as otherwise you would always have tags and potentially files changing or being deleted without any notification.

This is too big a risk, so I’ve shifted all of my tags out to the normal group structure and will work there unless this bizarro behaviour is changed, but one thing I already miss is the fact that adding a sub-tag to a file added all parent tags to the same file. Now if I add a sub-group to a file, to locate the file again I have to navigate to the sub-group itself rather than being able to widen my search to a parent level group and see all files under that grouping.

Ah well, at least I won’t lose any more files without even noticing!

Dan

5

The problems dantout discovered emerge with hierarchical tagging. That’s when tag replicants get wack.

6

The next release will fix this, in the meantime you could use the “Move To” submenu instead of drag & drop.

Neither over here, the documents are still in the database.

You could either exclude certain groups (e.g. “Books”) from tagging (see Info panel) or all of them (see Database Properties panel)