My schedule has been 'hanging' for a few days unable to complete. The archive seems fine, but the script just won't run. It doesn't stop stopping when I quit either. Perhaps a restart is what I need? It's done this before, and seems to be fixed for a short while after restarting (I shut down at the end of the week), but after running a backup once it does it again. I run OS 10.5.8 on a single processor PPC Mac 1.8ghz, and I back up to an external 500Gb drive where there is over 300Gb of free space. I back up files from an NAS server connected to the ethernet.

Matthew,

Without doing some additional research, it's hard to tell what might be going on. From experience, I can tell you that actions can sometimes get stuck when network communications breaks down, but it's not clear that this is the case here.

If you want to diagnose the problem, here's what I'd suggest:

- You didn't mention what version of QRecall you're running. If you have Help > Send Report... command in your QRecall menu, then start by doing that.

- Open the Activity Monitor application, filter on QRecall, and find the QRecallHelper process. This is the process that actually performs whatever action you're running (and is why it doesn't stop when you quit QRecall). Find the process ID number (PID).

- Open a Terminal window. Enter the following command

sudo sample PID -file ~/Desktop/QRecallHelper.sample.txt

... where PID is the number you found in the previous step.

Enter your account's password and wait for the command to finish. When it has, e-mail the QRecallHelper.sample.txt on your desktop to james@qrecall.com.

Now while you're still in the Activity Monitor, you can kill the QRecallHelper process: select the QRecallHelper process and use the Quit/Force Quit command. This is faster than restarting, and accomplishes the same thing (when you restart, Mac OS X force quits all stuck processes).

Nice one James - that's stopped the 'stopping'

I've sent you the txt file and also sent a report from Qrecall.

You built an excellent App here - it works very well - I hope sales reflect this!

Matthew

Matthew,

Thanks for the sample output and the diagnostic report.

Your QRecallHelper process is indeed stuck and I vaguely remember this problem.

It would appear that QRecall is encountering an I/O error from the volume containing the archive:

2011-10-26 10:13:23.675 +0100 Details archive I/O error

2011-10-26 10:13:23.675 +0100 Details Cause: <IO> cannot read hash entry { API=FSReadFork, Pos=620910680, OSErr=-36, Length=12, File='/Volumes/My Book 1/Current Work Backup.quanta/hash.index', Class=CarbonFile }

There's a bug in 1.1.4 that when this kind of error happens, an internal dead-lock occurs and the process gets stuck.

So I suspect that you're having random problems reading/writing to your external drive.

First, make sure there's nothing wrong with external drive's volume format. Use Disk Utility to repair the volume.

Then make sure the QRecall archive is in good shape by running a Repair on the archive. I would also highly recommend that you schedule verify, merge, and compact actions to run on a regular basis. At that very least, schedule a verify to run once a week. This will alert you to any possible data integrity problems that might have crept into your archive.

This could, ultimately, be a hardware problem with the external drive. Once you've done these repair steps, we can revisit the problem in more detail should it reoccur.

Thank you James for your comprehensive responses. I have reindexed the archive and ran a back up successfully
I'll keep an eye on the NAS and the back up disk - or perhaps also the switch (maybe the network has issues).

Keep up the good work!