Automatic syncing not exactly like anticipated


the new automatic folder synchronisation (version 1.9) is actually not what I had in mind :wink: Rather than having to keep track manually of each and every changed folder (or document for that matter) and subsequently tell DT to sync with that folder I’d rather have something like a check on every launch of DT, followed by an automatic retrieval of the documents that have been added/changed.

Taking that whish even a bit further, one could think of a flag connected to each item in the database, that could (optionally) tell DT to always or never sync with that item on startup.

The benefit of this feature would be quite obvious, I believe: Whatever I downloaded from the internet would be retrieved automatically into the Database on the startup of DT, provided I downloaded it into the right location. Whenever I worked on a word-document, changes could be reflected in DT after launching, without me having to remind DT. This way one could implement even a very rudimental version_history of a document: By automatically importing the new version without overwriting the old one (and puting it into some sort of hierarchy).

So, would after all this feature be to difficult to implement? Anyone else supporting this or having additional suggestions?

I agree with this, and furthermore, it is not really “synchronization” that DEVONthink performs on the selected folders, since it goes only one way (changes in the database do not get synched back to the Finder). Therefore synchronization as presently implemented is only a little more useful than manually deleting/reimporting, etc.

True synchronization would be VERY useful

It’s not that easy. But we’re already thinking of DEVONthink 2.0 which may bring relief here with some architectural changes.



Hi Eric,

thanks for the reply. As for full synchronisation I see the problem, but what is the problem with a (preliminary) one-way synchronisation? I mean, you already implemented manual synchronisation - now to do that automatically on startup with some given user-selectable folders should not be too hard to do – ?

Right now, changes of a file, done with an external editor (eg. changes in a word document) cause DT to overwrite the old contents of the corressponding database item with the new one, when synchronisation is invoked. I understand, that this is in most cases the desired behaviour of the sync-function. However, sometimes it would be quite useful if the new version of a file would be appended to the database instead of replacing the old contents. Append a “_version##_from:mod_date”-string at the end of the file name and you have a nice, searchable little version history.

To be honest, I believe, that all what the sync-function does at the moment is to delete the old contents of a group and reimport the content from the corresponding folder. Therefore, I see the problem that you face: Has a file changed its content (the modification date can be erroneous)? etc. However, I definately add this to my whishlist :wink:

Because then some people will want to have it sync every n minutes. Or instantly when they add new files. Or … DEVONthink Pro will come with an AppleScript that does exactly what you want and that you can alter if you should want it to behave differently.

And we have a new property for every group, because some people will not like it, others will want it with different settings for every group :wink: Also, you can solve this with DT Pro and AppleScript.

No, it really checks wich files have been added, deleted or changed. Your solution would be way too slow.



Cool. We do not fear change.

Change is our friend.


If you’re using DT Pro see this post for a simple example of how I’m using the Synchronize triggered script.

DT doesn’t delete an item from a group if the corresponding file is deleted from the filesystem but it removes the “lightning bolt” link, indicating a non-existent filename Path reference for the item. That behavior was recently changed since previously the “link-bolt” appeared on any item with a Path, regardless of whether or not the corresponding filename existed. The new way is definitely an improvement but it removed the ability to find older items in my database with a bogus Path I wanted to remove using the “Remove Paths…” script. I was about to see if the “Update Paths…” script would properly remove/ignore Path for selected items and DT decided to lock itself while I was navigating to some candidate items. Back to that later.

Hmm, that explanation might be followup for the other topic but I’ll post it here anyway.