How to trash only replicants, not originals?

Say I have a file, A, the original, and I make a replicant, B. “Get info” for each replicant indicates that there are 2 replicants total, and you can easily see by the dotted box symbol next to the file name that it’s got replicants.

My issue arises when I move 1 of them to the trash, say B. Now, neither A nor B indicates having any replicants; they both appear as an original, unreplicated file. The symbol disappears. This makes it impossible to tell, when deleting the trash for good, whether I’m deleting that file for good, or just deleting 1 of 2 replicants of a file.

When deleting hundreds of files, it’s totally inefficient to check each one to make sure I’m only removing replicants, not originals. Is there a workaround to this in DT3? Like some feature that allows you to see the # of replicants both in & out of the trash, and if not, can it be added?

There is no original replicant except in your mind, i.e., when you first created the item.
Each instance of a replicant is the same item. The only distinction is the location.

This makes it impossible to tell, when deleting the trash for good, whether I’m deleting that file for good, or just deleting 1 of 2 replicants of a file.

No, it’s not impossible. If the item in the Trash has a struck through name, there are no other instances of it in the database. If there is no strike through, there is still at least one replicant in the database. This is not new behavior.

6 Likes

Haha, I think as hard as it is for you to understand what problems others have with replicants, it’s just as hard for many others to understand how replicants work.

In my way of thinking, replicants are counter-intuitive. I could explain what would be “logical” for me, but that would be illogical for others :man_shrugging:

Conclusion: I can manage without replicants. :slightly_smiling_face:

That is perhaps or the best. That being said, I use replicants and find them invaluable. They are sort of like pointers used in some programming languages and for some pointers are stumbling blocks. Nevertheless, pointers and replicants are useful and used by many. Not an essential part of DEVONthink, as you note, but one of the features that is useful to probably many.

2 Likes

Yes, I am happy to leave replicants to those who find them useful. I suspect that some people who don’t understand them wouldn’t miss anything if they didn’t exist. But they torture themselves with wanting to understand something that they don’t actually need. Possibilities create needs.

Yep, different users, different experiences. To me they (replicants) are one of the most important features in my DEVOtNthink use.

I loath duplicates, love replicants :slight_smile:

2 Likes

@FrankT Don’t give up on replicants - they are very handy. Please permit me to invent some terms.

Groups in Devonthink aren’t real, physical things like file folders.

Think of groups like menus of files. If you move “ham sandwich” from the appetizer menu to entrees, Devonthink doesn’t actually move the ham sandwich file. It just republishes the appetizer menu, omitting ham sandwich. The next time you go to the entree menu, Devonthink will publish it for you, now including ham sandwich on that menu.

If you then replicate ham sandwich to the dessert menu, because who doesn’t crave a good ham sandwich for dessert, the dessert menu is updated. Devonthink is now aware you want to see ham sandwich in the dessert menu as well as in the entree menu.

Neither group physically contains a ham sandwich. If you publish ham sandwich in two places (replicate it), you’ve got two places to order your ham sandwich. You get the same sandwich from either place.

When you delete an instance of a file, it’s now published in the Trash group. If any other menu (group) lists the file, that listing will survive.

Once every instance of ham sandwich is published in Trash (moved to Trash), then emptying the trash will finally delete the ham sandwich file.

Drat. Now I’m hungry.

2 Likes

After all this time, never really knew what the strike through in the trash meant. Thanks for clarifying. Such a great app. Al
ways things to learn.

2 Likes

You’re welcome :slight_smile:

@Amontillado Thank you for your witty explanation. Very kind of you :smiley:. It’s not that I don’t understand it. I really don’t need replicants. But I understand that there are people who have trouble understanding these explanations.

So there is no “original”. There are replicants. You have “something” and make a second “something” out of it. You now have two “somethings”. Both “somethings” are the same.

image

DT shows me (above) two “somethings”, but tells me that there is only one “something”. One “something” is a replicant. What is the other “something”? An “instance”? Fine, but an “instance” is not automatically a replicant, it can also be a duplicate.

Again, it’s all good. I would know how to use replicants. I just don’t need them. :smiley:

I see what you mean.

Both “somethings” in your list are references to a single file. Either reference could be deleted without the file itself going away.

If you want more of a rabbit hole, tags are replicants with additional logic. :wink:

1 Like

Instead of “somethings”, my interpretation is
there is one file; it’s stored somewhere in a Finder folder
DT shows pointers to that file

2 Likes

I don’t think so, if I delete both the file is gone :slight_smile:

but if there are several replicants, then this number changes. Is it then no longer just one file?

image

The replicant count shows there are several pointers
to the one file, stored somewhere in a Finder folder

btw If you want to see the actual file and Finder folder, right-click the record and select show in Finder
You can confirm there’s just one file

No, it is not more than one item. This is described in the Getting Started > DEVONthink Simplified > Documents: Replicants section of the built-in Help and manual

Rhetorical questions are like irony, people usually don’t understand it. Of course it’s just one file. That’s why replicants don’t take up any extra space in the database.

The problem is a different one. But as I said, it’s all good. :slight_smile:

I’m afraid I haven’t fully grasped your specific concern regarding replicants.

Well, it’s my job to make sure things are clarified as much as possible :slight_smile:

Of course, I meant no offense. :pray:

That doesn’t surprise me. Sometimes I don’t even understand what I’m saying myself. :joy:

If I create a replicant from file A. Then the database shows file A (the original, which doesn’t exist) and file AR (let’s call it that), the replicant.

DT shows me two files, but tells me that there is only one replicant. What is the other file if it is not a replicant and there is no original?

No offense taken :slight_smile:

Development would have to comment on this, if they were so inclined. In your example, both files are replicants. But the Instances dropdown is intended to be read as “there is one more instance of the selected item”, which is technically true. There aren’t two more instances, only one. If you selected the other replicant, it would report the same thing.

2 Likes