Two databases stopped syncing - failed database verification

My global inbox and another database stopped syncing, which I didn’t immediately recognize and confused me for a while (files added to the global inbox showed up in DT but not in DTTG on other devices synced over WebDAV and the other way around).

Upon inspection, the triangle symbol in the menu bar tells me these two databases failed verification. When I opened the synchronization menu, these two databases apparently weren’t synced for a while.

I’ve got two question at this moment:

  1. Why did DT stop syncing these databases? Might this be the safety precaution related to the zero-bytes issue reported earlier this year?

  2. How do I repair these databases, as using the ‘verify and repair’ option reports something about orphaned files, but following repair the databases are still in a state where they ‘fail verification’ somehow

  1. If a database fails a verification, it will suspend syncing until the issue is addressed. And yes, it could be due to zero-byte files.
  2. Orphaned files are put into an Orphans group when repaired. If there are other issues that aren’t addressable via the repair function, they will need to be handled separately.
    What is reported in Window > Log?

Managed to figure out what files were problematic. I separated them in a database and then syncing resumed.

No zero-bytes it seems. Didn’t expect those, but as I understand now the sync process is deliberately halted when DT encounters any database error.

Thanks!

You’re welcome.

May I ask what specific problem those files were presenting?

They appear to be indexed records that lost the link to their original. I think I previously set them aside to look into why that occurred in the first place as I don’t regularly index, but I did experiment with indexing some files in the past. I’m quite sure it were these files.

Three files are reported to be approximately 3 KB in size, but they do not appear to contain useable content.

None of the files reported by verify and repair were zero-bytes. I just happened to remember a mitigation policy was put in place earlier, that intentionally stopped the sync engine to prevent any propagation of errors. It appears to gave kicked in somewhere around the end of October. Might it be some update occurred around that time to expand or change the behavior of the sync engine in case of errors?

I’ll try and recover the originals files from one of my backups, which more or less go back to the stone age. Based on their file names and thumbnails, most files weren’t terribly important and if all fails I’ll use the thumbnail. :grinning:

Edit: come to think of it, the most likely ‘cause’ is DT 3.8. I usually wait a few weeks after a new release is announced, which would be the end of October for me. Perhaps v3.8 is more strict when it comes to the preventive action of the sync engine when errors are detected?

Yes, that of the case.