I've had QRecall for several years, and I've run into a new problem. I can't open the archive, and QRecall can't tell me why.

Whether I'm trying to open it to look at it, add to it, or repair it, QRecall just sits and spins at "opening archive." Clicking the Stop button doesn't help, nor does quitting QR -- I have to force quit all the QR processes I can find. I've also tried a couple of reboots, to see if there was anything else in the way.

The archive is on a 3TB Free Agent drive. When I test it with the Disk Utility or with Disk Warrior, they tell me the disk is okay (it's only about a year old), but whenever QR is trying to open the archive, the console shows the kernel is throwing 'disk1s3: I/O errors' every 14 seconds. That error goes away whenever I force quit the QR, and the rest of the drive appears to be intact. There are a couple folders of smaller files on the drive, and they all seem to be intact.

After I force quit QR, the kernel gave a 'disk1s3: iotcl (_IOW, 'd', 24, 4) is unsupported error.

This is a 2009 iMac running 10.6.8. The rest of the files on the backup drive are okay. The archive itself is 1.54 TB, so I don't have room to set up another archive. I'm really reluctant to delete the existing archive (even though I can't get into it), so I'm ready to replace the external drive, unless you have some good ideas???

Thanks,
Kevin

Kevin,

I regret to say it, but I suspect that your hard drive is dying. There may be I/O errors in QRecall's log, and you're welcome to send a diagnostic report, but from what you describe it would appear that your hard drive is encountering read failures when trying to read certain regions of the platter—specifically, those that the QRecall archive occupies.

When I test it with the Disk Utility or with Disk Warrior, they tell me the disk is okay ...

Disk Utility, Disk Warrior, and almost every other disk utility out there, only validates the directory structure of the volume. They do not perform a comprehensive read/write test to confirm that all sectors of the drive are usable. You could lose a third of your drive, and Disk Utility will still report that it's fine. Any utility that reads the entire surface would require hours (and hours) to run. This is why QRecall's verify action takes as long as it does.

If you're interested in testing this theory, it's pretty easy from Terminal. You can run a simple command to read all of the data in the archive. If it's successful, it will finish after an hour or so. If there are I/O failures, the command should stop and spit out an error.

cat /Volumes/My3TBExternalVolName/pathtoarchive/ArchiveName.quanta/* > /dev/null && echo "No read problems"

Be patient. Even if it works, it will take a long time to finish. If the drive is encountering I/O failures, it will likely enter a retry/recalibrate cycle where it attempts to realign the heads and try again. Drives that are doing this run about 1,000 times slower than normal, so even if it hits an I/O error it could be many minutes before it's reported. You may hear the drive heads seek and clatter during this process. You can monitor the progress using Activity Monitor (switch to the Disk Activity tab) to see if it's still reading the drive or if the command has stalled. (Press Control-C in the Terminal window to kill the command.)

If you verify that it's I/O errors, you can attempt to recover the archive. You'll need a second volume with enough room to copy it. Choose the Repair Archive... command. Uncheck the "Use auto-repair information" option. (This is probably where your repair is getting stuck now.) Check the "Copy recovered content to new archive" and "Recover lost files" option.

This configuration will doggedly try to read every record in the original archive. Every record that can be read will be copied to the new archive. QRecall will then assemble the salvageable data into a usable archive. The "Recover lost files" option will collect orphaned files—files that don't belong to a folder because all of the folder information was lost—into a special "Recovered files" volume.

If the drive has a lot of damaged areas, the repair could run for days before it completes. So again, you'll need to be patient.

Thanks, and I'm afraid you're right.

I ran your shell script, and started getting IO error messages pretty quickly.

I'm currently recapturing everything to a new archive on a new drive. I'm keeping the bad drive on the shelf until this archive is complete. If something blows up in the meantime, I'll try recovering the original archive from your instructions.

Thanks again,
Kevin

I'm working on the backup (machine locked up last night, and I lost 6 hours of backup work), and I notice this recurring message in the Console:

kernel en0: can't handle af8

Googling it brings up nothing. Could it be yours?

Kevin Crawley wrote:kernel en0: can't handle af8

Googling it brings up nothing. Could it be yours?

Not a QRecall message. (Any QRecall message in the console will have a QRecall process name associated with it.)

en0 is the first ethernet adaptor. Probably something to do with IP traffic.

Alright, one more question, and then I hope I can leave you in peace...

The new archive on the new drive is done, and it's done it's first scheduled overnight capture. Somewhere, QR is still running the schedule on the original archive, and I can't find the schedule to remove it.

The Actions window only shows my new schedule actions. Paging through the dates in the future, that's all I see. The QRecall Activity window shows that the next action to be run is a capture on the old archive, and the log is showing that a capture to the old archive failed.

How do I get rid of that?

Thanks again for all your help.

Kevin

Kevin Crawley wrote:The Actions window only shows my new schedule actions.

That's the most definitive indication of what actions you have scheduled. I suspect that your status window (which is run by the QRecallMonitor app) is simply out of sync, possibly related to the problems you've had with your other actions.

Simple solution: Restart your computer.

If you want to try this piecemeal, use the Activity Monitor app. Start by entering "QRecall" into the filter field.

If you don't currently have any QRecall actions running, then there should not be any QRecallHelper processes running. If your find any, Force Quit (kill) them. (If the process is stuck on an I/O error, however, killing it won't work as the process is stuck in the kernel. You will have to hard restart your computer.)

Send a Quit message to the QRecallScheduler process. Then send a Quit message to the QRecallHelper process. Both should stop and then be immediately restarted (they'll have new process IDs when they reappear). If that doesn't happen then it's possible these processes are stuck in the kernel too, and you'll still have to restart your system. (Low-level failures really gum up the works.)