DT Hangs while "verifying" database

Subject pretty much says it all. The program will start up and will load my other databases but this particular one hangs about half way through the verification process. It opened fine yesterday.

Of all my databases, this one is really the most important. Any help would be appreciated.

Tom S.

If you search the help file (from the Help menu or the documentation) you’ll see the steps to take under the ‘Repairing a defective database’ section.

Thanks for the quick response and the suggestion. However, as far as I can tell, the options described in the help file require that the database be opened, which is not possible here. In the absence of anything better, I’m left with the possibility of restoring from a Time Machine backup - something that I’d rather not do as I will lose at least a days worth of work.

Tom S.

Tom - did you reboot? How about permissions on that disk - have you checked them in DiskUtilty, Onyx, or otherwise?

This isn’t what you want to hear, but if you need to restore from TM and are left with the possibility of lost data, here’s a method to locate the “lost” files. This takes work and involves the (free) FileMerge utility available on the OS X Xcode download from Apple:

Make copies of the restored and the lost database. In Finder “show package contents” and drag the folder Files.noindex out of each database to a new folder (renaming one of them). Use FileMerge to compare the two folders and locate the “lost” documents. This doesn’t help you with groups, tags, etc., but it is a life saver if you’ve been creating valuable documents inside a DT database and the database refuses to open under any circumstances.

Thanks, Korm. Sounds like a plan.

Cheers,
Tom

Has been anything logged to the system console?

The copy of the output to the terminal is below. I went a head and began executing Korm’s solution so there’s no hurry with this.

I should mention that this is probably my fault, not DT’s. I keep the database on Dropbox and I’m guessing that it wasn’t fully synced when I loaded the program up. Nevertheless, I don’t think the program, itself, should hang under any circumstances so it might be worth it for someone to take a look.

So for the purpose of “debugging” here’s the output to a terminal when I start the program and then try to load a copy of the corrupted package:

2010-05-13 06:08:08.986 DEVONthink Pro[357:903] HIToolbox: ignoring exception ‘*** NSHashInsertKnownAbsent(): item 0x1f030c70 already in table’ that raised inside Carbon event dispatch
(
0 CoreFoundation 0x924dfbda __raiseError + 410
1 libobjc.A.dylib 0x93802509 objc_exception_throw + 56
2 CoreFoundation 0x924df908 +[NSException raise:format:arguments:] + 136
3 CoreFoundation 0x924df87a +[NSException raise:format:] + 58
4 Foundation 0x986f94d2 -[NSClassicHashTable insertKnownAbsentItem:] + 159
5 Foundation 0x98665edf NSHashInsertKnownAbsent + 90
6 DEVONkernel 0x0053ab6a -[BRN initWithContentsOfDirectory:override:readOnly:fileName:fileExtension:count:backup:numberOfBackups:inFolder:mapping:swapIn:neuralNetClass:containerClass:containerSize:atomicClass:atomicSize:owner:progress:error:] + 6266
7 DEVONthink Pro 0x00085578 0x0 + 546168
8 DEVONthink Pro 0x00174211 0x0 + 1524241
9 DEVONthink Pro 0x001741a3 0x0 + 1524131
10 DEVONthink Pro 0x00179377 0x0 + 1545079
11 DEVONthink Pro 0x00175e80 0x0 + 1531520
12 DEVONthink Pro 0x0000879e 0x0 + 34718
13 AppKit 0x949ba5c6 -[NSApplication sendAction:to:from:] + 112
14 AppKit 0x949ba479 -[NSMenuItem _corePerformAction] + 435
15 AppKit 0x949ba16b -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 174
16 AppKit 0x949ba05a -[NSMenu performActionForItemAtIndex:] + 65
17 AppKit 0x949ba00d -[NSMenu _internalPerformActionForItemAtIndex:] + 50
18 AppKit 0x949b9f73 -[NSMenuItem _internalPerformActionThroughMenuIfPossible] + 97
19 AppKit 0x949b9eb7 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 336
20 AppKit 0x949ae5f9 NSSLMMenuEventHandler + 404
21 HIToolbox 0x993d50a9 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 1567
22 HIToolbox 0x993d4370 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 411
23 HIToolbox 0x993f6b55 SendEventToEventTarget + 52
24 HIToolbox 0x99423147 _ZL18SendHICommandEventmPK9HICommandmmhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 448
25 HIToolbox 0x99447e40 SendMenuCommandWithContextAndModifiers + 66
26 HIToolbox 0x99447df5 SendMenuItemSelectedEvent + 121
27 HIToolbox 0x99447cfa ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2 + 152
28 HIToolbox 0x99417436 _ZL14MenuSelectCoreP8MenuData5PointdmPP13OpaqueMenuRefPt + 454
29 HIToolbox 0x99416ba4 _HandleMenuSelection2 + 465
30 HIToolbox 0x994169c2 _HandleMenuSelection + 53
31 AppKit 0x949a7b3a _NSHandleCarbonMenuEvent + 285
32 AppKit 0x9497c6e6 _DPSNextEvent + 2304
33 AppKit 0x9497b976 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156
34 AppKit 0x9493dbef -[NSApplication run] + 821
35 AppKit 0x94935c85 NSApplicationMain + 574
36 DEVONthink Pro 0x00002e16 0x0 + 11798
37 ??? 0x00000001 0x0 + 1
)

I will keep the corrupted database around. Let me know if there’s anything I can do.

Tom

Version 2.0.3 will handle this, meaning that it won’t freeze in this case but nonetheless the database seems to be slightly damaged (probably due to Dropbox). Therefore v2.0.3 should be able to rebuild this database, just let me know (via PM or email) if you’re interested in the current beta.