Hi, James.

For a while now, 5 of my 7 archives have been in a damaged state. I attribute this primarily to the fact that the disk they are on is full and I haven't had the time to devote to pruning it. What I had hoped to do was get them functioning one at a time and then perform a Compact on each and see if that freed up enough space to continue to function.

The problem is that whenever I attempt a Repair, the process runs for a while and then multiple disks are ejected improperly?the drive on which the work is being done and one or another of others attached. (This will also occasionally occur when some scheduled action is being taken on one of the archives.) And at this point, the drives appear to be unmountable (they don't appear in Disk Utility) until after a restart.

I will probably move one of the damaged archives to another drive and see if I can repair it there and if that removal leaves enough room on the original drive to get the other archives repaired. But my point is that I don't think QRecall should ever cause a disk to unexpectedly eject, no matter what's going on.

Let me know if you want to look into this further and if my plans are appropriate.

Thanks!

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[1].

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.

[1] 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.

Sorry, James. That's why I included the quotes around "seems" in the subject. I didn't want to imply that I was accusing QRecall, just that it occurred during QRecall processes.

Disk Utility thinks the disk is okay. I will try the Recover process again this weekend. It ran happily for 13 hours until I had to abort to bring my computer to work.

I'll let you know the results of the experiment.