Bug Hunt: Hot on the trail of extra quanta hash entries

Greetings beta testers,

I'm trying to track down a bug in QRecall and I'd like your help. Here's the scenario that I'm looking for:

(1) You do something with QRecall 1.2 beta (capture, compact, merge, ...)
(2) You verify the archive and get an error that looks like this:

If you encounter this, please send a diagnostic report (Help > Send Report...) and then reindex your archive.

What's happening is that something, at some time, is deleting one or two data records from the archive but leaving the corresponding index entry for those records in the quanta hash index. In this example, the hash is supposed to have 48,064,742 entries (one for each data record), but instead has 48,064,744. This means that there are two extra entries in the index.

This is harmless problem from the standpoint of data integrity, since no archive data is missing or lost. But it is an inconsistency that I'm keen to nail down and eliminate.

The reason that I'm asking for help is that I've yet to duplicate the situation under which the problem occurs. Once it's happened, the information about what these phantom index entries referred to is already lost. I need to be able to analyze an archive, make the problem happen, and analyze the archive again. To do that, I need to figure out the sequence of events that causes it to occur. I'm hoping that if anyone else is encountering this problem that a review of their log files will reveal a pattern.

Thanks to everyone who sent in diagnostic reports!

Problem solved!

As it turned out, there was nothing wrong with the archives at all. Under a rare set of circumstances, the verify action would occasionally count the same quanta hash index entry twice, resulting in an erroneous total.

So if you encounter this error in 1.2 beta 5 or earlier, just ignore it—your archive is fine.

The fix for the verify action will appear in the next release.