Data loss risk: with multiple groups selected, moving replicated items to trash removes all replicants

Using DT 3.5.1 I’ve discovered an unexpected behaviour related to a new feature in 3.5.

  1. Select multiple groups in the sidebar
  2. Select an item that has replicants in other groups (which are not selected in the sidebar)
  3. Command-delete or right-click > move to trash
  4. All copies of that item are moved to the trash

This same behaviour also occurs if I have “unified inboxes” selected in preferences, select the top-level “inbox” group, and move a replicated item to the trash. It is then removed entirely, from the inbox as well as its replicated location (in this case, replicated via group-as-tag assigned at capture in the sorter).

Both cases are unexpected behaviour. It’s led to quite a bit of data loss in my case: I emptied the trash without realizing this was occurring and lost a significant number of items. I have backups, thankfully, so all is well in my case—but this should be either rectified, changed, or made absolutely clear at the time of the action so other users also don’t have unintended data loss.

Thanks for the feedback! Removing only one replicant is only possible in case of a selected group, e.g. it’s not possible in case of smart groups, search results or multiple groups as the desired replicant is not known. However, in this case…

…it should be actually possible. The next release will fix this.

Great news on the inbox fix!

To be clear on the intended behaviour - say I have three groups: A, B, C. Groups A&C have a replicant of a document. If I select only groups A&B in the sidebar and move the replicated document to the trash, will DT also move the replicant in group C to the trash? This is currently what happens and is quite unexpected! If this is the intended behaviour, there should be a warning of some kind as it’s easy to delete items unintentionally.

That’s currently the intended behaviour, an upcoming release might add an alert.

That’s a bit disappointing. Can you explain why this is the intended behavior currently?

I think rather than an alert, a better solution would be to only move the replicants in Groups A and B to the trash and keep the one in Group C. Why would anything else be intended?

Maybe my wording was poor, I should have said “expected behaviour”.

OK - but still, rather than give an alert, why not fix it to do what 99.9% of users would prefer (anticipate) it to do and which would be infinitely safer to avoid inadvertently deleting something important?

It’s not a simple fix but noted.

1 Like

Just a note:

why not fix it to do what 99.9% of users would prefer (anticipate) it to do and which would be infinitely safer to avoid inadvertently deleting something important?

Indexing is not the default option for a reason. It should be carefully considered, including ramifications deleting indexed groups and files. And DEVONthink has no concept of what’s “important”.

If you issue warnings, people want a way to surpress the warnings.
If warnings are surpressed, people are unhappy they got no warning.
Then the snake continues eating its own tail.

Did I misunderstand? I thought the issue had to do with replicants in multiple groups, not indexed files.

Haha! /facepalm
I started responding to you then was in a ticket and accidentally put in the wrong response. :grimacing::roll_eyes::stuck_out_tongue:
Sorry about that.

May I ask if this problem was fixed?

I would say it is definitely NOT the “expected behavior” with replicants as you should be able to delete one replicant and all others stay unharmed. Or did I get it all wrong?

It’s still a known issue (as fixing this is not trivial but requires a lot of refactoring).

Thank you for the quick answer, Christian!