unrepairable archive

I have an archive that I can't open, that keeps telling me the index needs repair. When I try to repair the archive, the repair appears to run normally, then fails to complete and close the file when it's done. This happens with the drive mounted on two different computers. Both Disk Utility and TechTool Pro give the drive a clean bill of health. Can you tell from the Report whether the problem is with the archive or with the drive, and if the former, how I can repair it?

Ralph,

I think it's the drive, but I need some more information to connect the dots.

The log included in your reports contains thousands of errors like this one:

2017-01-26 04:34:30.152 -0800 IO exception

2017-01-26 04:34:30.152 -0800 POSIXErr: 2

2017-01-26 04:34:30.152 -0800 Path: /Volumes/BUD2/2nd backup.quanta/repository.data

2017-01-26 04:34:30.152 -0800 ErrDescription: No such file or directory

This would indicate that the volume spontaneously unmounted while the repair was in progress. The repair is designed to tolerate I/O errors, and will keep plowing away, trying to read whatever data it can, so this just goes on, and on, and on.

The build in Send Report function only includes the latest log records, so to confirm my suspicions I'd need to more of the log. If you can, compress the files in ~/Library/Logs/QRecall and send them to me. They're likely to be very large, so I'll email you a dropbox upload request seperately.

Following up,

All of your repairs that I've looked at fail because the volume containing the archive spontaneously unmounts during the repair process. Here's an example of a repair that started at 09:49:

2017-01-21 09:49:40.052 -0800 Repair 5th backup.quanta

2017-01-21 09:49:40.052 -0800 archive: /Volumes/volume2/5th backup.quanta

Four hours later the volumes mysteriously, and spontaneously, unmounted. (Note that this doesn't appear to be associated with a sleep event.)

2017-01-21 13:34:42.401 -0800 unmounted volume /Volumes/volume2

2017-01-21 13:34:42.402 -0800 unmounted volume /Volumes/volume1

Not surprisingly, the repair starts encountering problems?about a million of them:

2017-01-21 13:34:41.999 -0800 problem getting volume statfs

2017-01-21 13:34:41.999 -0800 IO exception

2017-01-21 13:34:41.999 -0800 POSIXErr: 2

2017-01-21 13:34:41.999 -0800 Path: /Volumes/volume2/5th backup.quanta/repository.data

2017-01-21 13:34:41.999 -0800 ErrDescription: No such file or directory

This is most often caused by some intermittent hardware problem (failing drive controller, brief power interruption, flakey USB connection, and so on).

QRecall can actually be helpful in diagnosing this. Because the QRecall scheduler watches for volume mount and unmount events, it logs those when they occur. Filter out everything except the scheduler messages in the log, and then look for unmount events that shouldn't be happening. If your a command-line geek, this will also do the trick:

fgrep ' [3.' ~/Library/Logs/QRecall/QRecall.log* | fgrep mount