Lately I have been having issues deleting Replicants: When I delete Replicant folders or files in DTPO by dragging them to the DT Trash, I thought that the other Replicant copies/instances were not deleted or affected.
In the past few weeks, however, I’ve noticed that deleting Replicant files has become dangerous: deleting a Replicant seems to delete all Replicant occurrences. Sometimes it works correctly, but lately, most of the time, all instances of the Replicant disappear and end up in the trash. At first, it looks OK, like the other Replicants are still in the DT DB, but eventually it becomes obvious that all Replicants were deleted.
So I created a DT DB for “old files & previous versions to toss,” and I am starting to move files into that DB instead of throwing them in the trash. I have recovered some files from this holding area when I notice they are missing, but there are many other files that I inadvertently deleted (every copy of) that I won’t know about until the next time I look for them.
Am I doing something wrong deleting a Replicant, or has something changed in the program?
I hope this is a glitch that you have seen before and fixed, or are working on – I really hope this is not the first time this issue was reported!
I know of a case where deleting a replicant deletes all instances of the document. Say, the “original” was imported or created in a Tag group instead of a “normal” group – call the tag TAG – and then replicated to a “normal” group – call that group NORMAL. Then, navigate to the instance in NORMAL. Delete it. The instance in TAG is also deleted. So, we’ve lost both instances now. The reason for this the logic of tagging. For DEVONthink, tagging is replication to a child of “Tags”. If I get rid of a document then I get rid of the replicated item in that tag group. By the same logic, operating in reverse, if instead of deleting the instance in NORMAL, I delete the instance in TAG, then the instance in NORMAL is safe.
Not sure if this case applies to you. Not enough info about your use-pattern in the original posting.
Korm, Thanks for your quick response. I dug a little deeper to recreate the problem and describe it more clearly:
SCENARIO:
DTPO DB#1 has FOLDER-A, which contains ONE-FILE.rtf.
Create FOLDER-B.
Make a replicant of ONE-FILE, put it in FOLDER-B, and rename it REPLICANT-FILE.rtf,
Now both folders contain REPLICANT-FILE.rtf.
Move FOLDER-A to (DT) Trash.
FOLDER-B still contains REPLICANT-FILE.rtf, but it is no longer “marked” as a replicant: The file info window says 0 replicants.
REPLICANT-FILE.rtf in FOLDER-A in the Trash also says 0 replicants.
Now it looks like there are two copies of the files: my original copy, and the copy in the trash. And neither of them “appear” to be replicants.
CASE 1:
Empty Trash.
DB#1 FOLDER-B still contains REPLICANT-FILE.rtf. This looks right. So far so good. Just what you expected.
CASE 2:
Do not Empty Trash.
In this case, just to be extra careful with my critical files, instead of emptying the trash, I decide to move the files from trash to a backup DB: ARCHIVE-DB#2.
I am not touching my original masterfiles in DB#1… instead I am moving the “copies” in the trash into a different DB.
Now is when things get interesting: As soon as I move FOLDER-A (containing REPLICANT-FILE.rtf) from trash into DB#2, the original REPLICANT-FILE.rtf in FOLDER-B in DB#1 disappears. Now the only non-replicant instance or copy of REPLICANT-FILE.rtf is in FOLDER-A in ARCHIVE-DB#2.
As a user, I thought I was archiving or rescuing EXTRA COPIES of files from the trash in order to save them in a backup/archive DB. Instead, I was accidentally deleting the “non-replicant” ORIGINAL FILES, the “master files,” from my main DB#1.
My conclusion now is to not mess around with the trash: Empty trash probably works just fine. But once you start digging in the trash and moving files from trash into a new DB, beware that you are also inadvertently DELETING all the PREVIOUS EX-replicants of all those files from the original DB where the files came from.
DT behaves like the file copy in the trash is still a replicant, even though it is clearly marked as non-replicant.
And now that my head is spinning with The Knowledge About Replicants, I think these are the rules:
A. When you MOVE a file from DB-1 to DB-2, if that file is a replicant, then all the replicant instances in DB-1 are DELETED.
B. When you MOVE a file from DB-1 to Trash, and then from Trash to DB-2, if that file used to be a replicant, then all the previous replicant instances in DB-1 are DELETED.
“B” is just a case of “A”. When you move a file to another database, the replicants disappear in the “original” database because the file is gone. Replicants are not like copies – replicants are merely a way that DEVONthink use to make the same data appear in muliple locations. If you move the data somewhere else or delete it, then it’s gone.
BTW, the Trash is not something separate from the database. It’s just a type of group that isn’t shown with the other groups in a database.
korm is correct on this. The Trash is just another location in the database, albeit a special one. Just as the Tags groups contain replicants of files you’ve tagged, their names don’t appear in red as other replicants do. They also don’t increase the replicant count.
And also correct is the “move the file to another db and the replicant disappears” explanation since the “original” is no longer present to be replicated.
Wouldn’t it be less confusing if replicant names in the trash were in red? The replicants in the database would be red as well, until you empty the trash.
Because they are not marked as replicants in the trash, I started using those files as if they were copies. I thought I was being smart by moving “copies” of important files from the trash into a backup database. Instead, I deleted “original” master files.
Thanks for explaining how Replicants and Trash really work. Now I understand what to do and what not to do.
A safe approach is to ⌘C copy the item in one database and ⌘N “new from clipboard” create a new instance in the other database. (Don’t use ⌘V paste because that can have odd results in the destination.)
You can ⌘C ⌘N multiple documents at the same time – no need to do this one by one, though memory is eventually a limitation.
I had a related issue when trying the following use case.
Within my “work” databased I maintain a “reference” group with state regulatory filing documents. I wanted to make these documents readily available within a new “project” group. I replicated the folder for the particular state I wanted into the “project” group. I realized that there were a lot of documents that I didn’t need/want to see within the project group, so I thought I would delete the replicants within the project group. The problem was that it was the folder that was the replicant, so when I deleted (what I thought was) a replicant file in the project group, it also deleted the “reference” file in the reference group.
I think the problem was that I replicated the entire folder instead of individual documents. I started again by only replicating the documents I thought I needed from the reference folder, and in this case the individual documents behave as expected as replicants. I don’t think this is a problem with the software so much as me not understanding replicants well enough before trying what I did.
Correct. When you replicate a group, the replicants mirror one another, so if you delete a document in one replicant, the corresponding replicant group(s) also reflect that the document was deleted. The replicated group behavior is not unlike replicating an editable document-if you delete a paragraph in a document that has been replicated, the paragraph is deleted from all instances of the document.
I have hundreds of replicants I would like to delete, spread through many groups. I just want to delete the replicants within Group A and its subfolders.
When I use a smart-group to see them all (within group A), moving to trash moves all copies (included those replicated to Group B, C, etc) to trash. I’m looking for a solution to remove just the replicant and not delete the file entirely from the database.
Data > Move to Trash in a group removes only the selected replicant.
Control-click > Move to Trash in a smart group or smart rule removes all replicants despite their being an alternate command Move All Replicants to Trash when holding the Option key. I think this is a bug, but @cgrunenberg will have to respond when he returns from holiday.
In the interim, assuming you are removing all replicants from the group, you can create a smart rule targeting the A group, with criterion Item is Replicated. Then add an action of Move to Trash.
You can Control-click the smart rule and apply it to remove all replicants in the targeted group.
You can also drag and drop selected replicants in the results to trash them individually.
In both cases, the other repicants are preserved.
It is the “original” items in Group A I would like deleted. (Think of Group A and it’s subgroups like an inbox, and I have replicated the files to other groups outside of A. I’d like to delete the original copies in group A, and preserve those in other groups)
The options you suggest:
move to trash in a group: doesn’t work in my case because I can’t list all the replicants in one group. Only using a smart group. When I do Data > Move to trash from smart group all copies are moved to trash (with strikethrough)
control click: I don’t want to remove all replicants. Same result as above.
I have created a smart group targeting Group A, with criterion Item is Replicated. Those are the copies I want deleted, while preserving the others.
Ive tried smart-grouping replicants that ARENT in Group A (to duplicate them for example), but I still see the original file path, and move to trash from smart group still moves all, applies strike-through in trash.
Wow that was a terrifying “empty trash” click (700+ items) but it did indeed work! I noticed how you originally wrote it but didn’t have faith Thanks for saving the day again.
These were indexed folders. The path is still not updated, and it still shows the old location in finder. Some way to update that? (Tried restarting and also “update indexed…”)
I got myself into this mess by importing from evernote and its tags, so hopefully not something I’ll have to deal with again. Thank you!
Hmm. I noticed when I moved one item, the indexing functioned as expected (moving the item in finder). So I thought moving the folders in finder would cause a refresh in DT. It did. But. It duplicated all those items…
To recap:
What I wanted
Delete Replicants In Group A
Preserve in Group B
What I see
Replicants in Group A successfully deleted (according to DT Database)
Duplicates (in blue) in Group B (according to DT)
Replicants (in red) in Group B (according to DT)
No files or paths updated in Finder (except the one folder move I did manually that caused the new red & blue theme I have )
Thanks for saving the day again.
)