Direct Connection sync problems / verify & repair

DEVONthink Tips
1

I have sync problems with “Direct Connection” and verification doesn’t help
(DTPO 2.7):

  1. I tried to sync a database to another Mac via “Direct Connection”.
  2. Got error “Verification failed. Please repair the database using the menu
    command Tools > Verify & Repair.”
  3. I’ve done a verify/repair with the result of 1 remaining error. IIRC it was
    missing file or something like that.
  4. I’ve done a “Rebuild Database” which took a long time
  5. Re-tried to sync and got the same error as above
  6. Again verify & repair: No feedback (so no need to repair, I guess).
  7. Tried to sync ==> same error.

I can successfully sync some of my other databases. Others have the same
problem as described above.

(BTW: It is confusing that – even successful – syncing doesn’t give any
feedback / progress indicator. Also Verify & Repair should give some feedback
if everything is ok.)

2

Rebuild probably will not fix a missing file. To fix, run V&R. You’ll get the error. Open the Log. Look for the entry that says “missing”. Navigate to that document. Delete it. Empty the trash. Run V&R again and you should be good to go.

(This process should be simple. It is not. Another feature request, perhaps? :confused: )

3

This can be enabled via the following command entered in Terminal.app:


defaults write com.devon-technologies.thinkpro2 DTSyncLogSuccessfulSyncs -bool YES

Some people like it, some don’t.

4

Thanks for that!

5

No, V&R is fine now, but the sync log still tells me to V&R. Another database also was successfully repaired (w/o need to rebuild), and there also the sync log tells me to do it again.

6

Sync is just calling the V&R routine internally, so there’s either something wrong with the V&R routine or something wrong with the database.

7

Yes, it seems so.

In other words:

If the database is corrupt, why V&R (from the menu) doesn’t report it? (and hopefully repair it.)
If the database is OK, why V&R (internally called by the sync) does report it as corrupt?

8

Some more info:

The databases that sync without problems are all small databases (the largest
has 170 files / 100MB).

The databases that produce the error and don’t sync are somewhat larger
databases (e.g. 900 files / 300MB or 30000 files / 1GB)

9

Those are still pretty small. Have you ever kept any of these databases in a Dropbox client sync folder?

10

No.

11

Please open a support ticket.

12

Yes. What I was trying to do was find some common criteria for the problematic databases. Size was the only one that I’ve found (so far).

I’ve opened a ticket. Thanks for your help.

13

It seems that I have found the cause.

There have been inconsistencies also in the sync target’s databases. I repaired these and now all databases sync without problems.

So V&R from the menu only checked the local database while V&R called by the sync also checked the remote (target) database. Hence the different results. (It would be useful if the error log tells me which database has the issues.)

Sorry for the noise. Anyway, it is good to know that also the target database has to be issue-free. I didn’t consider this at first because I assumed that (unidirectional) syncing would – by nature – overwrite any faults in the target database (provided that the source is faultfree).

14

Although I wish this were possible, it’s not.

Wait… holy crap. I think it’s possible that it’s actually doing this. omg im a genuis

15

You’re welcome :wink:

16

That’s hilarious. I was actually thinking, “hey, I should totally implement that.” Never would’ve imagined I apparently implemented it on accident.

17

Yes, but does it make sense?
I’m no database expert, but if the source database is verified a one-way sync could/should just overwrite any potential issues in the target database, no?

18

If it were a one-way sync, yes. But it’s not.

19

Does this mean that files in the “target” database that have a more recent modification date or that don’t exist in the “source” database are backsynced to the source?

20

OK, I tested it. It’s really two-way. I’m pleasantly surprised …

So it is indeed very good that you’ve implemented “by accident” the verification of the remote database :wink: