Rename Replicants

I searched on the forum and did a site search using Google, but I couldn’t seem to find anyone else mentioning this. If someone has brought it up already, I apologize. It seems brutally obvious and I can’t believe that no one’s asked about it before.

My question: how difficult would it be to rename one replicant without renaming the others?

I understand that the current behavior might be desirable for some people, but it’s not for me – in fact, it makes replicants unusable, since the names of my articles change based on where they are located in the group hierarchy. I’ve never used replicants, hence my surprise that there hasn’t already been a few people complaining about this.

Could there be a preference for individual or collective replicant rename operations? A menu option for whichever behavior isn’t default?

Interesting request, but one that would change the fundamental purpose of replicants – to allow multiple instances of a group or document, with low database overhead. In keeping with that purpose, any change made to any instance of a replicant affects all other instances in the same way.

It’s true that in the Finder one can create an alias of a file, then change the name of the alias without affecting it’s link to the original file.

But there are important distinctions between an alias and a replicant. The existence of a replicant logically implies the existence of another “matching” replicant – a single replicant cannot exist. The existence of an alias also implies another file – the original file to which the alias is linked – but it’s quite possible for there to be an orphaned alias if the original file were deleted, in which case the orphaned alias loses any referenced content. But it’s not possible to have an orphaned replicant. That’s an important difference. If I have two replicants of a document, I can delete either one without losing information. If I have an original and an alias, I can delete the alias without losing information, but if instead I delete the original document I lose all its information and the alias becomes an empty ghost file.

I suppose that DEVONthink could have adopted the Finder convention of making aliases of original files rather than that of replication, when one wishes to create smart groups, or to select a list of search results and save the listed documents into a new group without moving the original documents. Perhaps such alias documents could display their names in green. That would allow you to do what you have requested, the ability to rename such aliased documents without affecting the originals.

But there would be management consequences, notably the potential of losing information when originals are deleted, and leaving orphaned alias files without content scattered throughout the database.

All in all, I prefer the freedom of using replicants for organization, with the security that if I delete a replicant I haven’t accidentally lost its associated information.

Note that you can do what you requested by choosing duplication rather than replication of documents. You are free to rename duplicates without changing the names of other files. True, there’s an overhead penalty in database size.


I know that replicants aren’t the same as aliases. They’re most similar to UNIX hard links which, I should mention, can be renamed. In fact, the default behavior of the CLI utility is to make hard links, not symbolic links. In other words, this concept is not new and in fact is fundamental to the operation of any modern file system or database, although the ability to add new instances of hard links is not necessarily implemented.

So I don’t really care about your thoughts and feelings regarding the philosophical and practical differences between hard links and aliases or symbolic links because they have nothing – nothing – to do with the ability to rename hard links. The ability to rename a hard link is a minor technical issue and should not (in any sane database) be answered with anything other than “Yeah, of course that’s possible, we just haven’t done the GUI coding yet to expose it to the user.” Bill, I could code an application that allows renameable instances of hard links. I could do it in QBASIC, a Bash script, an AppleScript, XCode, with sheets of paper, with an abacus. This is the most basic problem of database design and it was first solved decades ago.

But since I’m here and feeling good and patronized, let’s take a whirlwind tour of your argument that this is impossible or impractical.

“The existence of a replicant logically implies the existence of another ‘matching’ replicant – a single replicant cannot exist.” This is the entirety of your argument, and this is where I began to think that you were simply throwing words at me out of sheer force of habit, Bill, because it doesn’t make any sense. If there is no original and no copy, the two records are identical, and if that is the case then the content must be stored in a separate table from the metadata because to do otherwise would necessitate either pointers or duplication, both of which are logically and empirically excluded.

The only way that the above would not hold true would be if the record metadata is stored separately from the record content – except, for some perplexing reason, perhaps blackmail or ransom for a kidnapped child, the developers decided to store the record name in the same table as the record content. There would be no benefit that I can think of and, in trade, versatility would be lost – for instance, the ability to rename instances of a hard link.

In other words, and using a vocabulary that is more tangible than the DEVONtechnologies-approved lingo: Single hard links do exist; in fact, every item in a database exists in the form of a hard link to data stored or described in a separate table. To suggest otherwise is to describe a database layout whose poor design contradicts principles of elegance, versatility, common sense, and the functionality we observe every day.


Very interesting post indeed. If I understand, you say that a single replicant is possible, because all record names are “single links” of some data. And different names to that data are possible, as names are hard links.

However, I wonder if replicants in DEVONThink are “hard links”. Maybe the way they developed their database works differently. Maybe the database layer is too far from the cognition of the user : most users don’t know or don’t care if records are hard or soft links. What is difficult is to explain and to justify is he logic and the difference behind duplicates and replicates. Personally, I tend to think that DEVONThink is a little in the middle between a real database metaphor and a file explorer one (iTunes vs the Finder, for example). That may cause a lot of difficulties for most users.


Touché! Yes, philosophical. Or analogous to Schrödinger’s Cat and the quantum theory of superposition of states, perhaps. That’s because the nature of replicants in a DEVONthink database is unfamiliar to and somewhat shocking to most people.

Most people relate a document to something physical, such as a stack of sheets of paper held together by a paperclip, or a range of pages in a bound journal, or the journal itself. The information content of such physical objects can be stored into a computer, and most people will tend to see a correspondence between lists of files displayed on a computer screen and a collection of physical documents. The filename is the document. A file can be selected and moved, deleted or opened to be read. One begins to think of it as an object. We have a lifetime of experience with objects.

Duplication of objects – of files – is easy to understand.

Many people are a bit surprised when they first encounter the use of alias files. An alias is not the object itself, but is a reference to another file. The conventions are pretty simple. An alias can be deleted without harm to the “real” file to which it refers. And if the “real” file is deleted the alias file becomes useless, an orphan without a reference. Not too difficult to grasp easily.

Replication of files is much less intuitive. We associate a physical object such as a stack of paper to a particular location, a place. And we tend to associate a file to a location in the computer’s file structure. The introduction of alias files doesn’t break that association. But the introduction of replicants does. A single file can be located in more than one place, and – unlike files and aliases – the place in which one chooses a replicant instance for action upon it doesn’t matter. That’s shocking to most people. The conventions for dealing with replicants are different in important ways from those applying to ordinary files or to duplicates. But once those conventions are grasped, replication becomes a very useful tool.

Most people come to database use without a programming background and that’s why the philosophical approach seems to work better in explaining replication. :slight_smile:

You are quite right in noting that Christian adopted conventions for replication that don’t meet your specific needs for renaming replicants. The Name of a document is metadata, and all instances of a replicated document currently use the same metadata tag. That convention could be otherwise.

I suspect you are using scripts to rename documents according to grouping. The problem is that renaming replicants in a specific group changes the names of all instances of replicants throughout the database. That problem would be eliminated were you to duplicate files rather than replicate them, but of course would add to the database size and memory footprint.

I’ll note your suggestions to Christian.

Holy cow, Bill, I just wrote a several-page post and you made it irrelevant :laughing:

Okay, that’s what I was afraid of. So I assume that replicants are merely additional values in a “location” field or something along those lines. Kinda creeps me out, but it apparently works well enough, and avoids some of the oddnesses of the model I was expecting (namely, that the mischievous among us would change the creation date of one replicant and not the other to satisfy some strange kink).

Nah, I don’t use scripts to rename documents. What I’ve gradually shifted to, over the past year and a half or so that I’ve been using DTP, is using titles like:

I.A.23.a::047.  [[Essay]]  How I Learned to Stop Worrying and Love the Relational Database

with I.A.23.a meaning the specific place in the folder hierarchy where the document is located, 047 being the position of the document in the list view, and [[Essay]] being the rough type of the document. It’s basically as specific, unambiguous, script-friendly, and compact a system as I can come up with. I use scripts to increment and decrement the position numbers of documents if I need to insert or delete another one, to copy the real title for the alias for easy wiki-linking (since, by the way, I hate the floating Info window), and so forth. I traffic in relatively small numbers of documents (a few tens of thousands) that must be controlled very tightly, so it works well for me so far.

Renameable replicants would make it easier and cleaner for me to keep the same content in multiple places, but I wanted renameable replicants before I began using this organizational scheme. I don’t think they’re particularly useful for people who deal in large numbers of documents and have no interest in micromanagement – I get the feeling you all use the search and classification functions a lot more than I do. I think it’d definitely aid with the makeshift tagging we Big Fish in a Small Pond types do.

I just came across another use case:

I store all my office documents in a database, so let’s say tax stuff goes into:

Gov’t > Canada > Taxes > Income Tax > 2008

But in 2008, I also had to file taxes in Germany, so I also have a folder

Gov’t > Germany > Taxes > Income Tax > 2008

Now I’d like to replicate those 2 “2008” folders into a general “Taxes 2008” folder. Of course, this way I end up with

Income Tax > 2008 > 2008 (being the replicant of the Canada 2008 Income Tax folder), and
Income Tax > 2008 > 2008 (being the replicant of the German 2008 Income Tax folder)

What I would have liked to have is
Income Tax > 2008 > Canada
Income Tax > 2008 > Germany
where each of the two folders “Germany” and “Canada” are replicants to the respective 2008 folder.

The only solution I can see right now is to give all folders unambiguous names, such as “Income Tax 2008 Canada”. Given that I only have a 15" monitor, this becomes quickly unusable for more realistic, i.e. more deeply nested, settings.

Replicants have a different location, so I could envision them having a different “Display title” as well. Each of a files replicants would still share a common name (“2008”, or “Taxes Germany 2008”, or whatever), but the different replicants would get, in addition to their respective location, a separate “Display Title”.