Thanks for the follow-up!
Installed 3.0.3 ā 276 of 278 ghost files were reportedly restored. After checking some samples across the whole database this seems indeed to hold true. I am very relieved and want to thank everyone here who contributed to the solution and the guys at DevonTechnologies for taking us serious and working with us on a swift solution.
5 Likes
This was only an issue with 2 minor files for me, but I likewise want to appreciate the work in fixing this. Huge load off my shoulders to not have toi worry about my databases anymore.
This aside, v3 is off to a great start so far, and Iām very excited for further new features down the road.
3 Likes
Good morning. I updated to DTTG 3.0.3 and what can I sayā¦ I left DTTG last night in the ghost-file group view and after the update this morning, the over 450 ghost-files where replaced by a working one from DTTG 2-Database, even before the change log dialog came up.
Really impressive job und lots of thanks for the hard work!
My trust in this piece of wonderful software is restored.
5 Likes
After the update to 3.0.3 the file is gone. Thanks.
1 Like
you mean that in a good way, I presume? So the ghost has gone and everything is ok again?
I donāt want to spoil the party, but please all be aware that the root cause of this situation is yet to be determined if I understand correctly. That means (in theory) the problem can re-occur, despite the terrific job the DT staff has done in such short amount of time with the automatic replacements.
When people start deleting their DTTG2 installation or newly added files become āghostsā there is no backup available in DTTG2. Perhaps @eboehnisch has an idea? I presume itās not desireable to create an incremental backup system on iOS while awaiting further cause analysis.
@cgrunenberg might comment whether some temporary ābuild-inā backup on DT (i.e. on macOS) could do the same as the DTTG2 ā DTTG3 replacement does on iOS. That would at least help out those with a DT/DTTG3 combination, and doesnāt require manually restoring ghost files.
That doesnāt actually delete the DTTG2 data right away. It might, of course, be useful to delay the deletion.
If the current theory is correct, namely that the problem was lying dormant, having been caused by a problem in DTTG2 a while back, then itās possible that once it has been rectified once, it no longer appears. But I guess the last word hasnāt yet been spoken on that.
I heard Ericās sigh of relief from hundreds of kilometres away 
Now that the immediate problem is solved, I guess the team will be back with a clearer and happier head, looking at what is actually going on. I look forward to feedback on what the root actually was (assuming Iām competent to understand the explanation, that is). But we can have a little party in the meantime. (Well, weāre still in the middle of a pandemic, so we canāt - how about a cup of tea? Masked, gloved and alone.)
Yes. I couldnāt delete this file in the ghost group. Actually, my statement belongs to a comment string with @eboehnisch.
Thanks 
Iāve lost track 
The analogy couldnāt be more striking: donāt celebrate early, as things can come back to āhauntā you (pun intended). The automatic replacement is great, but also hides issues from occuring and therefore the size/width of the problem will decrease only based on this mitigation. My suggestion would be to keep looking for ghost files and the cause of course in the mean time.
Without knowing what caused the situation, newly added files cannot be restored in this way I presume. Youāre correct in that just deleting DTTG2 will not remove the data store as was mentioned above, but people might also remove DTTG2 first and then install DTTG3. Although itās fairly unlikely of course. And as said, new files will be added in the mean time. Are those added in duplicate to the DTTG3 and DTTG2 data store? To be clear, the exact internal workings of DTTG go beyond my knowledge.
If the DT staff can be sure about the cause, the situation would be completely different. But based on my āforensicā analysis the files became āghostsā on the exact day of the DTTG3 upgrade. Itās difficult to understand why DTTG2 would ācauseā that.
The files restored by version 3.0.3 should be synchronized back to the Mac.
Yes, but thatās not what I mean.
The DTTG2/3 replacement is a temporary mitigation of a problem with a yet to be established cause. It only works with āoldā files and not with new ones and also not on devices that never had DTTG2 installed.
But as I see it, DT could perform a similar kind of action. Whether itās the trouble of creating that is up to you of course, but how do users repair newly added files might they occur in the future. Iāve done it manually, but that requires some work and restoring complete databases also restores any changes that were made in between the time the āghostā appeared and those changes were made.
From what I understand (and guessing the rest), by causing damage to the file in the sync store. Presumably that damage never propagated, because at the same time, the file was never marked as updated. If the file actually was ever updated, the damaged file in the sync store would have been overwritten, and so would also not have propagated. When DTTG3 was introduced, presumably some mechanism then let these files go.
I repeat: The first bit is what I gathered from what Eric wrote. The rest is (my) guessing. If there is any truth in my guess, however, it would mean that the problem will not recur; and to date, this thread has not suggested any ānewā files being affected, so the theory would at least hold water.
(Iām not suggesting your suggestions are invalid; I think we as users are called upon to check our backup strategy; I will be keeping my 0-size smart group and checksum script for the time being; and I agree DT would be well advised to look into any other necessary precautions)
Thatās at least our best assumption so far and explains why we canāt reproduce this. As far as I remember, there have been no reports of new files being affected.
The upcoming DEVONthink 3.6.3 will also improve File > Verify & Repair Databaseā¦ plus the simple, automatic verification before synchronizing a database.
1 Like
That goes for me as well, but the pinned notice mentioned they werenāt sure yet as @eboehnisch wrote.
If this is the cause and no new files appear youāre right of course.
Yes, but the chance of the files being reported has also been reduced with the work-around. To repeat, itās a terrific way to restore the files and I have deep respect for the timely way it was done, but itās still a work around if the cause is not understood.
Whether or not DT should pursue it further is up to the staff of course. But if you donāt find a cause, based on what the staff have reported my estinate is that the most āsureā way to prevent new occurences is to remove DTTG2 and DTTG3, setup a new sync store from DT and resync all devices. It might be that is not necessary at all, but itās like restoring a computer once in a while to get rid of any āghosts from the pastā 
If the database(s) are intact on the Mac, then yes, deleting 2 and 3, then reinstalling 3 and reimporting the databases is a viable option (one Iāve successfully prescribed in support pre-3.0.3).
However there have been no reports of new files being affected. And no issue has been reported in a fresh install of 3, i.e., for new DEVONthink To Go users.
1 Like
Itās not unlikely that the cause has been fixed a long time ago, e.g. while developing DEVONthink To Go 3 or maintaining the sync engine which steadily receives improvements & fixes.
And that would also explain why neither we nor our testers experienced this because all of us use the latest versions and have to reinstall apps and clean sync stores for tests quite often. Although I also have sync stores which are many years old and work flawlessly all the time.
My point is: that could and could not be a proper way to measure the size of the problem.
How do you know? File integrity is exactly what I think people do not check. Iāve never had the need to setup a 0-byte smart group, just bumped into this thread and there they were. But what about files that arenāt zeto-bytes but less than the original because they;re missing critical bytes?
And weāre back to my checksum script
1 Like