Steven M. Alper wrote:But my point is that I don't think QRecall should ever cause a disk to unexpectedly eject, no matter what's going on.
That's an excellent point, and I can assure you QRecall would never do such a thing. In fact, QRecall can't do such a thing even if it wanted to—and it would never want to.
The most an application can/should do is request that a volume be unmounted. QRecall only does this for actions on external volumes following the successful execution of an action. It makes no such requests at any other time.
Furthermore, this is a request, not a command. The filesystem is the entity that unmounts a volume, and will only do so after all files on that volume have been closed. So any open files (and repair will have multiple files open until its done) will prevent any software from unmounting the volume.
Finally, there's no way to unmount a volume (unless the drive can be physically ejected) in such a way that it can't be remounted again.
My conclusion: there's something wrong with that volume/drive. I'd defiantly perform a volume repair to look for structural damage (which is more likely the fuller a volume gets). But the fact that the volume can't be mounted again makes me suspect hardware issues, which are often bus related. Try switching communication paths (i.e. switch from FireWire to USB), or change drive enclosures, if you have that option.
Steven M. Alper wrote:I will probably move one of the damaged archives to another drive and see if I can repair it there ...
This is the most sensible approach.
An alternative, which is also an experiment, would be to use QRecall's "Recover" mode when doing the repair. This mode only reads data from the source volume, and writes the reconstructed archive to a different volume. The reconstructed archive will have no empty space, although it's possible that it could be made smaller still by compacting again. This is much faster than copying an entire archive and then repairing the copy, because the repair and copy happen in a single pass.
The experiment is that if the volume spontaneously ejects simply while being read, there's definitely a hardware problem here.
 There is a "force eject" function in the OS that can force a volume to eject with open files. QRecall certainly never calls this, but some other software might. But it's far more likely volume structure corruption or hardware is the cause.
This message was edited 1 time. Last update was at 07-Jan-22 11:48