First I got an error that the archive needed repair. Then for a couple of days I've been getting errors "Lost Connection With Process."

Using QRecall 2.0.7 on Sierra.

Mike,

Send a diagnostic report. (Choose Help > Send Report, in the QRecall application)

It's possible that the process is still running, but since it happened multiple times I suspect the repair process is crashing. The diagnostic report should shed some light on what's going on.

Mike,

I would appear that the archive was damaged (no idea how) and that your redundant data files are now out of sync with your archive's primary data file.

This can be a problem for the repair. The redundant data is designed to correct with small amounts of data corruption—a byte here, a 4K block there. It cannot deal with massive amounts of bad data, and when the redundancy files get out of sync it makes it appear as though all of your data is bad.

This can usually be remedied by discarding the redundant data and repairing your archive. I have plans to add this option to the Repair command, but for now you'll need to do it manually:

1) Select the archive in the Finder. Right/Control+click on the icon and choose "Show Package Contents".

2) Locate the repository.data file.

3) Locate any "companion" file; these will start with "repository_" followed by a series of letters/numbers, and end with extensions like .checksum32, .anvin_reed_sol, .reed_sol, and so on. (If there aren't any, then redundancy isn't enabled and you can skip the next step.) Here's an example:

repository.data             <---- keep this one



repository_8k.checksum32    <---- trash all of these

repository_p8w8k16m2.0.anvin_reed_sol

repository_p8w8k16m2.0_8k.checksum32

repository_p8w8k16m2.1.anvin_reed_sol

repository_p8w8k16m2.1_8k.checksum32

4) Select all of the companion files and trash them. DO NOT TRASH the repository.data file.

5) Back in QRecall, repair the archive.

6) Once repaired, turn redundancy back on using Archive > Settings…

Thanks, working on it now. The repair has been going on for an hour and has "examined" about 1/4 of my data. I didn't realize it would take so long; I need to shut down my computer in a couple hours.

This is the second time my archive has needed repair. Any advice about how to minimize these occurrences? It is possible that my hard drive was unplugged without ejecting it--maybe that is what damaged the archive. That is only speculation, however. I don't recall seeing any messages to that effect from OS X.

Mike M wrote:Thanks, working on it now. The repair has been going on for an hour and has "examined" about 1/4 of my data. I didn't realize it would take so long; I need to shut down my computer in a couple hours.

You can stop the repair, but it will have to start over again. The repair takes so long because it has to read and verify all of the data in your archive, then reassemble the various tables and indexes it uses to manipulate it.

This is the second time my archive has needed repair. Any advice about how to minimize these occurrences? It is possible that my hard drive was unplugged without ejecting it--maybe that is what damaged the archive. That is only speculation, however. I don't recall seeing any messages to that effect from OS X.

QRecall should be able to recover from most abnormal interruptions; the notable exceptions are the compact and repair commands. So just unplugging a device won't necessary corrupt your archive, unless the timing is just right, but should still be avoided for obvious reasons.

On the other hand, stuff happens. That's why we take backups and why QRecall is so fastidious about monitoring the health and integrity of the archive data.