I used “duplicate to” to create a test DB (DB2) for some selection of files from my main DB (DB1) which is using indexing. After that I assumed that files are duplicated to a 2nd DB and imported them into DB. What happened is that original files from the mac were imported and I now have a serious mess at my hands …
But just that I understand the process:
DB1 > indexes local files
DB1 > duplicates to DB2 - files are still local files?
DB2 > moves into DB2 - original (?) files are moved into DB2
What is a proper way to achieve what I actually wanted?
So, I have a DB1 which indexes my local files on PC.
I did a search in DB1 and wanted to export the result of this search in a new DB2 for experimentation w/o impacting original files. I clicked “duplicate to” DB2 for a search selection assuming this will only create duplicates of the files inside my new DB2.
After that I clicked “move to DB” assuming that this will have no impact on my original (indexed) files - that was a mistake. Files were moved from Mac into DB2 at that step.
What I want to achieve:
create a copy of selected files from DB1 which uses indexing in a brand new DB2 w/o impacting original location of the files on Mac. How do I approach this in a right order?
I did some testing and I am a bit confused as I am trying to understand this very powerful feature to avoid future mistakes.
According to DT’s user-guide:
Key points are “examines content” and “separate files”. So my assumption was that duplicant does create a separate file (in comparison to replicant) when I select “duplicate to”. This does not seem to be the case.
Now, my test experiment:
In DB1
I have created a folder with 2 files in it on a desktop:
Files are basically saying File1 and File2 in them e.g. so there is some “content” and not only a file title.
And indexed this files into a DB1:
We see on the icon that files are in finder e.g. indexed.
I did a scoped search for these files in this folder
these files were found and clicked on both of them and selected “duplicate to”
and selected a folder in DB2
In DB2
According to DB2, these files in DB2 now do not have duplicates. .
And they still point to the same files on a hard-drive which I originally indexed into DB1.
(Then I selected “move into DB1” assuming I am only moving duplicates in DB2, and this moved original files from mac > which was exactly what happened in my original post).
Where is my thinking error with this?
Can I assume then when original behaviour was “indexing”, duplicate to does not create a copy of a file?
What I am trying to achieve is “to create an independent copy of the files in DB2 based on a search in the indexed DB1”
Where is my thinking error with this?
Can I assume then when original behaviour was “indexing”, duplicate to does not create a copy of a file?
Duplicating a file in one database is not the same as duplicating across databases.
The only one I can see to accomplish what you’re trying to do is this…
Duplicate the file(s) in the same database. This will create new files in the Finder.
Select the new files in the database and Control-click > Move into Database. This will move the copies from the Finder into the database. (Note the filename of the duplicates will not reflect the filename in the Finder, which has an appended number, so they will appear with the same filename after moving them into the database).
Move the files to your desired location in the other database.
PS: This is yet another reason indexing isn’t the default option when handling incoming files. It’s not a simple decision in many cases, especially when you’re trying to do unusual actions like this.
Thanks @BLUEFROG. That was not known to me. While re-reading the documentation for DT 3.0 I see no mentioning of that. There is statement that replicants only work in one DB but there is no information on the behaviour of duplicates across DBs.
Duplicating a file in one database is not the same as duplicating across databases.
Can you expand on this? Why is this feature then still called “duplicate to” in the menu when I duplicate to a different DB if it is not “the same”?
The solution you suggest is a way to go, what I do not like about it is that it changes the original names of the files. I am still looking for a way to create duplicates i.e. 1:1 copy in a new DB (basically to say in linux terms “cp -avr DB1/(selection of a search) DB2/folder”).
Unfortunately, I need to rely on indexing as not all my data sits in Devon and require things like Drive, Dropbox etc.
Why is this feature then still called “duplicate to” in the menu when I duplicate to a different DB if it is not “the same”?
Because it’s still a duplicate operation. This is no different than duplicating in the Finder. If you duplicate in the same group, you will get copy appended to the name. But if you duplicate to another location, you will get a file with the same name. Same operation but with different results due to the location you’re targeting.
The solution you suggest is a way to go, what I do not like about it is that it changes the original names of the files.
In DEVONthink, the filenames aren’t changed. Since these files are imported now, it shouldn’t make a difference. If so, please explain why it would.
The only 1:1 option is to import the files from the Finder into DB2.
so there is some “content” and not only a file title.
.