Interesting Replicant Behavior (or a bug?)

DEVONthink
1

I was trying out replicants to see how they work and to make sure I understand them.

I created a note in my Inbox.
I moved the note from Inbox to Notes.
In Notes, I choose ‘Replicate to…’ and choose Inbox (or another folder)

All good here, the note shows as a replicant and editing in one changes the other.

I move the note that is in the inbox to Trash.

Still good here. Note is in both places. Note that the path for both points to the same physical file and that the replicant relationship has been lost.

Now move the note from Trash back to the Inbox.

Oh Oh - the note is now NOT in the notes folder anymore - the one in Inbox is the only copy.

Is this the right behavior? I don’t think that’s what I would expect to happen. I think that when the note is moved back to the inbox, it should be a replicant again, not the sole instance of the document.

2

Here’s what I see

  • create new note in Inbox
  • replicate it to another group
  • have “replicants 1” in Inspector, both records are shown as replicants
  • move the variant in the Inbox to trash
  • in the trash, it is a normal record
  • the remaining variant in the group is also a normal record without replicants
  • Moving back the note from trash to the inbox gives me the two entries in Inbox and the group, both marked as replicants

Note: I used the context menu to replicate and move to inbox, and the delete key to move to trash.

So, I see something that looks a bit irritating, but definitely no loss of information.

3

Are you referring to the Inbox of a database or the Global Inbox and is the Notes is a separate database?

4

Global Inbox - doesn’t matter.

If I replicate to inbox and then move the note to another folder, there are two and are replicants.

Move one to trash and then move from trash back to the folder and the second one disappears and there is just a single document.

5

I have a single database

6

That’s not what you said in your first post. There, you moved from trash to inbox:

You can’t have replicants of a document in the same group:

Note: Replicants cannot be created in the same location as the originating file, nor can they be made across databases.

(from the documentation)

And please note that there are no folders in DT (unless you’re talking about index Finder folders). DT has groups. Those have no equivalent in the file system, whereas the DT documents do.

7

While it’s not incorrect to only use the Global Inbox, its intended purpose is to temporarily hold transient or unfiled documents. Think of it in the same way as its real-world, analog… analogue :stuck_out_tongue: Imagine if you tried to use the Inbox on your desk at work as your filing cabinet.

Are you referring to imported or indexed documents?

I think that when the note is moved back to the inbox, it should be a replicant again, not the sole instance of the document.

This is exactly what I am seeing. Pulling the document from the Trash and putting it back in the database’s Inbox, returns the replicant status for both instances.

A screencast of the behavior you’re describing could be helpful.

1 Like
8

Here’s a screen capture recording. Not using the inbox at all.

9

Thanks for the screencast!
It appears to be a bug but of a very specific kind and yes, I confirmed the behavior here.

In your screencast, you do not specifically select the database’s Trash. You grab the file from the top-level Trash group and drag it back into the database. I did not see the behavior you mentioned as I was dealing specifically with the database’s Trash.

Development will have to look at this.

10

Interesting - glad you found the difference. I replicated your scenario grabbing from the database’s trash and that worked as expected.

11

Thanks for the confirmation as well!

12

The next maintenance release will fix this. In the meantime don’t move the item from the unified trash but from the database’s trash back.