Missing manifest caused by dual booting or something else?

Today I got missing manifest messages on two iOS devices. No other indications of any problems. I read up and did thorough verifications and ended up cleaning the databases…which took a looooong time to resync across two computers and three iDevices. The manifest messages have all gone so I think I am good again.

I believe the cause of this was an experiment I started yesterday dual booting two OSes installed in different volumes on the same computer, both with DEVONthink 3 set up using Dropbox sync store. I suspect I rebooted to the other volume before the first one had finished syncing, and then back again. The kind of message in the Thorough Verification was “broken or not yet complete data structure”.

Does this sound a likely cause? If so I expect you will advise that dual booting is dangerous, but before giving up on it is there a way I could confirm syncing was complete in the future before rebooting?

Could/should I close the databases before rebooting to the other volume?

I have posted this in the DTTG section because that is where I saw the manifest messages, but it maybe a DT3 issue.


I also got the “Missing manifest”. For me it’s for the “Inbox” database in DEVONthink To Go ver 2.8. Don’t know what to do about it. Items in Inbox are synced to other units so that part is OK.

Will be interested in official replies, but pretty sure you will end up cleaning the sync store for the Inbox database. Easy to do and for the Inbox quite quick (unless you keep a lot in inbox).

Cleaning is started from Prefs > Sync. Select your sync method then right click on the database you want to ckean. Select Clean from the drop-down.

Done and fixed! Thank you for your help.

I am now pretty sure my problem was an initial setup problem. After I had setup the second volume I noticed syncing wasn’t happening, so I re-set it up. At that point it hadn’t sync’d for a day and had quite a lot to do. I think that is when I interrupted the sync by rebooting to the other OS.

Since then I have been observing sync more carefully and see that it is very frequent, so most of the time it is up to date and a reboot would be OK. This seems to be confirmed by rebooting between the two OSes a few times without problem and no further missing manifests.

Interrupting the sync and its garbage collection could cause such issues (usually temporary until the sync is resumed), version 3.5 fixed this.

Thanks for the reply. I am using 3.5, so you are saying that if I had left the missing manifest errors they might have fixed themselves?

I am also interested in what you haven’t said, ie that I shouldn’t be dual booting with DEVONthink active on both volumes.

Version 3.5 fixed the issue but there might still be manifest issues left from earlier versions. A verification of the sync store might be a good idea.

Dual booting is basically like running DEVONthink on two computers. But as the databases are the same ones in both cases probably, this can e.g. cause unnecessary up/downloads and bloat the sync store. If the databases are definitely used in both cases, I would recommend to create an alias of ~/Library/Application Support/DEVONthink 3/Cloudy and use it on all volumes.

Thanks Christian.

Before cleaning the three affected databases I did do a thorough verification of one them, which took a long time and produced some messages about “broken or not yet complete data structure of database…”. I could see it was heading to cleaning anyway, so went straight to cleaning for the other two. Are you suggesting a thorough verification now, after cleaning and re-syncing? BTW Normal verification always passes.

Not sure what aliasing that Cloudy folder does, and I guess I could also point DT at the databases on just one of the volumes as well, to avoid having two separate sets of database files, but my objective is to keep the two volumes as independent of each other as possible, even if it means unnecessary duplication.

No, this isn’t necessary after cleaning anymore.

The suggestion is only useful if you should use one set of database files.

Thanks for clarifying.