All of a sudden I started getting verification errors when DTPO syncs:
I’ve done the “Verify & Repair” on both databases that returned an error, and this is what came back:
But repairing doesn’t seem to work. The error just happens again.
Where is your database located?
I’m confused about that. I am using Dropbox to sync, but when I go to Apps > Databases the folder is empty. I recently upgraded from the beta to 2.5; I wonder if something got broken then?
The original databases reside on an internal drive (not the boot drive) in my Mac Pro.
Without synching, I’ve been baffled why a single “Missing File” repeatedly shows with Verify & Repair even though it has a document item and can be found with Show in Finder.
Of course! The repair routine cannot add missing files!
The DevonThink team tends to recommend a ‘rebuild database’ in such cases, but in my experience the following (much easier) procedure works too (and if it doesn’t you can still try the rebuild): control-click on the missing file error message and choose ‘reveal’ in the contextual menu. This will reveal the reference to the missing file. Control-click on that reference and move all instance to DEVONThink’s trash. Empty that trash before you sync again. Make sure that ‘verify and repair’ doesn’t report errors anymore and do a ‘backup and optimize’ to prevent the error from recurring.
Hope this helps!
The problem is that each time I get a verification error, different files are involved. That’s what doesn’t make any sense. For example, at the 3pm sync I get an error that one particular file is missing from a database, and then at 4pm all of a sudden that file is no longer missing anymore. (I have made no changes to that database in the interim).
What does this suggest?
Arnow,
Your solution ended up working. Thanks a lot!
If a file is reported as missing but is physically present in the database package (as @sjk reports), then it is possible that the reveal/delete procedure suggested is merely revealing a non-missing file and eliminating it from the database. IOW, is the reveal/delete procedure removing the possibility of an error message by removing the user’s data?
The term ‘missing file’ is misleading. A ‘missing file’ is technically an entry (reference) that doesn’t refer to a file. In other words, when you reveal a missing file you reveal an entry that doesn’t refer to a file and when you delete that entry you delete only an entry, not a file. If the file to which the entry originally referred is still in the database that file will turn up as an orphaned file, unless there are one or more other entries in the database that refer to that file. So, as far as I know, by deleting a ‘missing file’ you don’t remove user’s data, except for that one entry (not the file to which it used to refer).
In the case of SJK I suspect that the entry reported as ‘missing file’ is not the same as the entry used to find the document. I am not sure about that because (s)he doesn’t provide details about how (s)he proceeded after the verify in which the missing file was reported. However, (s)he can easily test whether I am right in the following way:
-
do a verify and repair (it is important that you finish the repair even though it will not solve the problem!) and reveal the ‘missing file’ from the entry in the log window.
-
do a ‘show in finder’ on the entry revealed in this way, copy (not move) the found file (not: the entry) to a safe place outside the database. Leave the finder window open to see what happens in step 4.
-
delete the entry revealed in step 1
-
empty DEVONThink’s trash
-
What happened to the found file? Is it still in the folder discovered in step 2? Good! Is it deleted from that folder? Not good. Don’t worry though, import the copy you’ve put in a safe place in step 2 and you are done (because the discovery that the files is deleted indicates corruption I recommend in addition a rebuild). If the file is deleted from the folder, please let us know. For in that case Korm is right that my recommendation might lead to the removal of an error message at the cost of data loss and I should retract it.
Do you mean the “Missing File” appearing in the Log when running Verify & Repair looks like, but really differs from, the other normal document item and corresponding file?
[Coming back here after composing the rest of this, I doubt that’s right]
I’m he - S(cott). I’ve only repeatedly run Verify & Repair.
There’s no “repair” step. This is the only dialog that appears:
Show in Finder is inactive, greyed out in the context menu for the Missing File in Log.
As mentioned above, there’s only the one normal-looking document item with its corresponding file, which may not be what “Missing File” refers to. I just deleted it after making a db backup (in case Dtech might be interested in look at its pre-delete state).
…/Files.noindex/.txt/0/get E3000 manual (Mar 21, 2011 8-12).txt was trashed when deleting the document, and running Verify & Repair after that found it there. Gone from the db after Empty Trash, then Verify & Repair ran clean.
Ahh! I just realized the dot-prefixed “.txt” folder component in the pathname instead of just “txt”. Not sure why the file was there (did DtPO consider it corrupt?) with its normal-looking document item, but it seems that’s why Verify & Repair was grumbling.
The file doesn’t look corrupted and I put it back in DtPO, but it’s disposable now anyway.
In all my years of Dt usage this was the only time Verify & Repair repeatedly reported anything. Other errors have been rare and only reported once with clearer reasons than this.
I consider this resolved even without fully understanding it. Thanks for all the help, guys!