Moving from DT databases to indexed files and folders

Hello there,

I would really appreciate some feedback, tips or suggestions regarding the following topic:
As I move more and more to a paperless “lifestyle” using the fabulous DEVONThink Pro Office, at the same time data safety and backups are becoming more important to me and I have one particular concern: I use Arq to do my offsite backups. In Arq, one can view all the backups for a given folder and see the exact changes done to every file. That is, for every point in time a backup was done and for every file one can see whether it was added, modified or deleted.

If on the other hand a DEVONThink database is backup up, this only applies to the database file as a whole, not for every file inside the database. If I accidentally delete a PDF and notice months later, as far as I understand there is no easy way to find out which version of the backed up database file contains that PDF. I would have to restore many versions of the database file and see which version contains the PDF.

My questions are:

  1. Is my above description correct, or is there an easy way to find the correct backup record for that file?
  2. To solve that problem, I might change from using databases in DEVONThink to indexed files and folders. If I do so, is there a way to preserve the identifier of the files? In other words: If I have a file inside the database than can be reached using the link “x-devonthink-item://898192C4-03B1-4FA5-A4AB-61AF1E4E837F”, is there a way to export the file, index it and find it using the same link?

I hope my English is more or less understandable and would really, really appreciate any feedback.


If you export a file and then index that exported file, it will have a different Item Link (x-devonthink-item) than the non-exported file.

How does this solve the “lost file” problem?

Hello korm,

thank you for your reply.

Yes, that is what I was trying to describe.
I am looking for a way to export a file, delete the non-exported file, index the exported file while maintaining the same item link.

This is not possible currently. Every import gets its own UUID.

Why? What is the problem you are looking to solve? You mentioned your distrust of the Arq backup – how will the UUID solve the trust issue?

I didn’t say I wouldn’t trust the Arq backup. What I want is to see the backup history of each and every file, not only of the DEVONthink database file. Therefore, I consider exporting and indexing every file. And because I have set up many links to files, I was looking for a way to do so without changing the UUID.

Alright, thank you very much. I will try to come up with some kind of automation to replace the old UUID with the new one in my links.

What you can do is as follows:

  1. Create a folder in the file system
  2. Index that folder
  3. Move documents or groups into that indexed folder
  4. Select the moved documents, and chose the Move to External Folder command from the contextual menu

The moved documents will now be indexed documents and they will also retain their Item Link (UUID). Note that if you repeat this, with one or more new “top level” indexed folders you create first in the file system, then you can eventually move the entire contents of a database into the new external folders. If you however move the documents in the file system out of those “top level” folders, the indexing will break.

Don’t take my word for it. Try this yourself on a sample database. Going as far as backing up the database with Arq or whatever.

1 Like

Thank you korm,

that seems to be a very good solution. I will definitely try it out!

Thank you, korm, for the very helpful reminder. I use indexing in a few of my DT databases. But I was struggling to think of a way to change from a “housed document” structure to an indexed version for a very large store of scholarly PDFs.

Your clear (and timely!) explanation was just what I needed. Thanks!


I’m facing the same problem - moving a DT internal group hierarchy to an indexed group hierarchy. It wasn’t clear to me if this is done on a group by group basis of if indexing the highest level group/folder was sufficient before applying the move to external folder command. I illustrate below

In this case I would like to move all the contents of Folder 2 into an indexed group hierarchy (the mint green groups) as illustrated by the black arrow. Assuming I indexed the new group “Folder 2” within DT, can I then export “Sub-folder 2” to the new “Folder 2 - indexed” group and all groups/files below “Sub-folder 2” will be moved and retain their DevonThink URL ?

Sorry, I don’t 100% follow the story. If Folder 2 and it’s sub-folder hierarchy is indexed, then Sub-Folder 2.1 and Sub-Folder 2.2 will be indexed as well. Within DEVONthink (or with Finder) you can drag any of the contents of the second and third level subfolders into the indexed Folder 2.

I’m not sure that’s what you’re asking. What I would do first to check this out is create a mini-scenario in Finder and test these actions.

Perhaps I wasn’t clear enough. Let me try again: Folder 2 and subfolders are not indexed e.g. groups within a DT database. I create Folder 2 - Indexed in the file system and ask DT to index it. I then export Subfolder 2.2 within DT to Folder 2 - indexed. My question is whether the sub subfolders will be indexed automatically as they are subgroups to Subfolder 2.2 ?

You make a good point - I can try it out with a low risk first.

Yes, and your test should confirm that.

1 Like

Gotcha. As @Greg_Jones said – yes. But you don’t need to “export” (unless that’s just a metaphor). You can move any indexed folders or documents around within the indexed Folder 2 hierarchy however you wish, and as long as you stay within the folder 2 hierarchy in DEVONthink, the results of those moves will be reflected in the filesystem as well.

1 Like

Confirmed. My experience shows you have to select the highest group in the hierarchy that you want to index and simply moved that group into the indexed group. Thanks @korm and @Greg_Jones .


Great! That’s an important factoid for anyone looking to index: index at the highest level you might want to work with.