I use DT on my Mac, my iPhone and my iPad. Now I run into the problem “Duplicate database UUID” when trying to synch. What to do? I can’t really describe what I have done before, what could have created the problem.
Did you duplicate a database in the Finder? Or open a database and a backup of the database at the same time? These are the most common reasons.
I am not aware of that but I have to check. I had problems with my (external) SSDs. So I had to open an older Version from Time Machine. Maybe that is the problem. Would it help to create new DBs and move the files to these?
Did you open multiple versions of the same database at the same time? Only switching back to an older version shouldn’t cause this error.
This would be the case as I normally do not close DT when I finish working on it. That is the case for Mac, iPhone and iPad. My plan would be to focus the synchronisation on one DB at a time to find out which DB creates the problem. Let us give it the name P (for problem). Then I would create a new DB S (for solution) (let’s say on the iPhone) to which I would move the files from P and synchronise that one (S) with the Mac. So that I have S also on my Mac. Then I would merge P and S on the Mac and delete duplicates. Then I should have all files from P as well as the additions in the new S. Would that be a feasible approach?
The easiest solution is probably to replace the current database in the Finder with the desired older version from Time Machine while DEVONthink is not running. But first I would recommend to back up or compress the current database.
I thought I did exactly that, but I may be wrong. As the content was and is quite critical I was a little bit excited to say the least 
That’s exactly why creating backups (the more the better) is usually our first recommendation.
Absolutely correct. But when you see two Samsung SSDs with originals on the one and backups on the other failing more or less at the same time → Houston, we have got a problem! Disk Drill offered me over 180.000 files with let’s say only limited value because of the sheer number of files. In the meantime I was able to work with a Time Machine backup from another drive accepting to have lost some work of a couple of weeks.
What exactly did actually fail?
The first was no longer mountable. However you could see it in Disk Utility. The fixes there did not help. For this reason I used Disk Drill and stored the results (the 180.000 files) on the other SSD. But before I was able to really go through all of these files the second one was suddenly no longer visible also not in Disk Utility. This has not helped to increase my confidence into the Samsung SSDs. But, shit happens and life sucks. So now I work with what I have and care for a comfortable work environment a little later.
We recommend as much backups (ideally on multiple devices and locations, e.g. in the cloud too) as possible and especially not to rely only on Time Machine.
Anyway, are you able to open the older, restored version? Is a verification via File > Verify & Repair Database… successful?
Yes I was able to open earlier versions. But as I had changed the DB structure of my setup in the meantime, some work is lost. So, for the time being I will focus on my Mac and work on the synchronisation later. (It also helps to reduce complexity and thereby increases my focus;-))
Well I tried to repair the database and rebuild. it didn’t help. They still have the same UUID. And I don’t know know how to fix that. I have four databases with the same UUID.
I don’t know how to change that short of creating an empty database and pulling everything over which I also tried but then failed for some of the database folders or groups. So that wasn’t very useful either.
My original mistake has probably been that I have copied and pasted the database files in Finder so that I can reuse the structure inside. But now that I have done that years ago, I see no way of fixing that.
There is no “fixing it”. There is only properly creating new databases and migrating documents to it. And if you are referring to many, many thousands of items, I would not try to do it all in one shot. If you aren’t using item links for document linking, you can use File > Export > Files and Folders to export from the old database then File > Import > Files and Folders in the new database.
And if you have emails in the original (which I believe you will IIRC), those could inhibit some transfers.
Thanks @BLUEFROG - for replying on a Saturday, in particular. So I’m probably close to be through by first, on each database, doing a rebuild, then creating an empty database, then dragging everything over from the rebuilt database into the new one. This seems to have worked. One thing I noticed along the way is that having the database folders part of a Seafile library is probably a very bad idea. Conflicts are just killing it then
I wonder whether what I’m experiencing with another installation is related: That person is likewise using DTP to absorb all their emails. Now for one database, very frustratingly, they’ve lost access to all their emails starting a random day this year - like, Jan-8. Now we have those mails still in the mail server, so what we did was, just import them again. That worked for a while, then they were again gone, for the same cut-off date.
We then had the idea about Seafile being involved, and hence we just removed that Seafile Library so that Seafile would no longer touch those files at all. We then again re-imported everything that had been lost and thought we might have solved the issue.
Turns out, this morning, to our great frustration, it happened again - DTP reporting, with the same cut-off date, the mail files as all missing. I’ve said to them, I’m using exactly the same mail absorption process (using a local imap server), and I’ve never had any problem (certainly not at that scale), so something is not working on their end, and they should stop using DTP for that purpose.
On the other hand, I’ve like nearly 2 million emails on my database, and while I’ve the odd missing file, it’s never at the scale of thousands, it’s maybe 5 mails per database. At most.
Now, as today I ran across that UUID issue - and yes I now read your mail that you’ve said so since a bazillion years not to copy databases in Finder, which I certainly will not do anymore, but which is nonetheless at least a surprising behaviour (but that’s not the point here) - and since I am now rebuilding all my own databases, I’m thinking of giving it another shot with that other customer of yours to just rebuild the database entirely, which would get rid of all the missings, then create a new database, move what remains over there, and only then re-absorb (what we fortunately still have) on the original mail server.
Thanks again for your quick response.
You’re welcome and that’s certainly not how anyone wants to spend a weekend… or even a weekday!
Refresh me… are you indexing the filesystem to get the emails in? Just wanting clarification as you do use the word “import”.
I can’t speak to anything Seafile-specific (indeed it’s pretty uncommon amongst our userbase, as far as we have data). But given how seems to be implemented, there could be technical reasons behind some of the issues you’re seeing. It would be easy to test with non-Seafile data but likely difficult to pinpoint something given the scale you’re using. If it failed at a very small scale, you should be seeing much more disruption.
Hi there, so we finally found the problem and it was our own stupidity. we had a backup created by Carbon Copy Cloner of our database into a different folder. The user had opened that database from that different folder, from that target folder. So he now had opened two databases with exactly the same name.
He did not notice and when we restored the missing files, while we still do not know why they went missing in the first place, we did so into the backup database. So now the files are restored, the database is in order. And suddenly, well, when the next backup runs, that backup database gets overwritten with the real database where the restore never went into.
In other words, the files that were missing are removed again. Hence they go missing again. That was the entire problem that we were having.
1 Like