Hello,
If I duplicate a group between DBs, it copies the enclosed files (correct)
if I duplicate without specifying the type =group, it copies all items without preserving the tree structure.
so how can I use devonthink to sync 1 DB folder to another DB folder, keeping its structure of subfolders and files unchanged?
can I, or I need to use another tool or a script?
my goal is to have a 1way sync from one DB to the other.
sorry, update:
the script doing “duplicate to” actually seem to delete the records in the source after creating them in the target, after db synchronisation and index updating.
in the screen below, the search in is an iCloud Drive, and the duplicate to is in oneondrive mapped in finder.
This would definitely require a script.
What’s the purpose of this actually?
It’s a backup.
But it is unexpected that DT deletes the records In the source after duplication into another DB, right?
What’s the advantage compared to e.g. Time Machine or other backup solutions? E.g. there are several backup solutions that can synchronize or copy folders like that.
This is indeed a bug in case of indexed items duplicated to an indexed group in a different database, the next release will fix this.
1 Like
Sorry, wrong words. It’s a backup in the sense that I copy it to another folder in another cloud solution as one of them could be unavailable at times.
I know, don’t judge 
. I’m working to make the cloud connection more reliable too.
I would definitely recommend a dedicated third-party software which just copies/synchronizes from one folder to another, this would be also more efficient as smart rules can’t perform the same tasks.
hi, getting back on this after some time.
so, I removed the duplicates and did the copy on my own.
the issue seems to be, if after indexing I move the groups from one db to another (for me databases are aggregations of multiple cloud and local sources), it works up to a certain moment and then the folder is recreated back in the original database.
so DB 1 linked to folder A with subfolders B and C
DB 2 containing folders “Foo”, “Bar”.
I drag folder B to DB2 and it moves perfectly, it also updates. then after some time (a week? more?) the subfolder B reappears under DB1.
so my question is: is this foreseen? is there a way to stop the folder being recreated twice in DT, without indexing every single folder or having to move around the real folders to fit this purpose?
Did you try to move indexed subgroups from an indexed group to another database?
Yes that’s what I did.
I had an indexed folder and moved the group from its dB to another (non-indexed) dB.
In that case it’s basically working as expected, the files are still indexed after moving them to a different database and therefore in the original location in the Finder, meaning that an automatic update of the original indexed group due to filesystem events will add them again.
You could either move them into the database before moving or duplicate them to a different database.
my understanding is then that I have to sync indipendently each folder of the original database up to the level I want to move to another database.
I understand the mechanics but I suggest you put this out very clearly inside the application because it means users have to rework their finder folder structures to meet DT’s requirements.
it also means that I need to remember at which level I defined the DT indexing in a finder location, when I create folders in finder, to be sure they are created correctly.
this is an issue for one drive and iCloud that have some folders created automatically that cannot be moved to fit DT requirements.