Direct Connection sync problems / verify & repair

Sync compares the two records’ modification dates and the date at which the machines were last synced. If one of the records’ modification dates is more recent than the last synced date, that record is copied to the other machine. If both are more recent, there is a conflict and the user is asked to choose which one should be kept.

Am having a very similar problem. Direct sync between two machines of one database. Same error messages and misbehaviours as described above. Have not been successful in fixing this despite the above helpful thread.

Have tried the above steps: V&R (ran it on both machines); deleted orphaned files; emptied the Trash on both machines; did a V&R from the Tools menu on both machines. I still get the following error in the log:

12:01:08 PM: Sync: DTirma130720 → Harriet.local. (Direct Connection) Harriet: Error Domain=com.devontechnologies.DEVONthink.Sync.DTLocalSyncStore Code=4 “Verification failed. Please repair the database using the menu command Tools > Verify & Repair.” UserInfo=0x107b106d0 {NSLocalizedDescription=Verification failed. Please repair the database using the menu command Tools > Verify & Repair.}

I can send the full log but does not contain much more detail than that.

I’m not quite clear what you guys are referring to when you mention running V&R from within Sync.

Anyway, thoughts or suggestions?

I’m not quite clear what you guys are referring to when you mention running V&R from within Sync.

The V&R that is automatically called by the sync.

Ah, ok, thanks.

So, next steps. Previously when I have had problems similar to this (versions 2.5, 2.6), I resorted to starting over again. This time it did not seem to help.

On what I regard as the master machine, I did the following:

  1. Tools | Verify & Repair
  2. Emptied the Trash (actually nothing there)
  3. Tools | Rebuild Database
  4. Checked for Orphaned Files - zero this time.
  5. V&R again
  6. Tools | Backup & Optimise (which shrank the file from 406MG to 359MB - good)
  7. V& R again
  8. Removed previous sync connections
  9. Copied the .dtBase2 file over to the target machine. Opened it from there.
  10. Set up sync in the other direction, using Direct Connection. (Functionally, I have found it better to have it this way round, with the target being on what I would regard as my server machine, because then I can more easily set up sync from a third laptop. Seems a bit backwards but worked better this way in v2.6). However, at this point, there is only a sync connection between two machines.
  11. Tried to Sync - get the same error messages again. “Run Verify & Repair” … which does nothing.

This error message is now showing up with two identical files. So I guess that there must be something internal that it is still not happy about. But what to do now after all the above steps is hard to know.

It suggests to me that V&R is not doing the job that it should be. Not enough info in the diagnostics or log files to know what needs to be fixed now.

BTW, am running the most recent v2.7.1 on both machines.

  1. V& R again
  2. Removed previous sync connections
  3. Copied the .dtBase2 file over to the target machine. Opened it from there.
    […]
  4. Tried to Sync - get the same error messages again.

So in other words you are copying (cloning) a verified database to another Mac,
and the freshly copied database already fails the first V&R (called by the sync
command) …

In my (amateurish) understanding this should not happen, except you have
read/write problems on the disk of the target Mac. Did you try to run ‘Verify
Disk’ from ‘Disk Utility’? (and maybe ‘Verify Disk Permissions’ too)

Yes, I thought it was odd too. That is my fallback for when nothing else works. Sync from a fresh copy. Not this time.

Thanks for the suggestion re Disk Permissions. Ran that on both machines. Did not help. Checked the read-write permissions with Info in Finder. Is 777.

What next? Anybody else got any other suggestions?

Yes - start a Support Ticket after turning on the verbose logging per the earlier instructions in this thread, attaching it to the Ticket.