I just wanted to follow up on this. Today I downloaded the latest beta (1.1.0(15) beta) and tried again with a new archive. It still ran through the entire list of network users, but it did so MUCH faster, in only a few seconds. The backup proceeded after that, and everything appears to be fine.

I can send you the log if you're interested.

-- Bruce

James,

I'm seeing the following message every 10 seconds or so in my console log:

2/16/08 3:45:15 PM com.apple.launchd[85] (com.qrecall.scheduler) Throttling respawn: Will start in 10 seconds
2/16/08 3:45:26 PM com.apple.launchd[85] (com.qrecall.scheduler) Throttling respawn: Will start in 10 seconds
2/16/08 3:45:36 PM com.apple.launchd[85] (com.qrecall.scheduler) Throttling respawn: Will start in 10 seconds

This is with QRecall 1.0, on a G4 iBook. The problem was evident from when I first upgraded to QRecall yesterday. At the time, I was running Leopard 10.5.1. Since then, I've upgraded to Leopard 10.5.2, gone through numerous reboots and QRecall relaunches, yet the problem persists. Any idea what's going on here?

I'm not seeing the same problem on my Intel iMac (which also received both QRecall and OS X 10.5.2 upgrades yesterday), nor on the Intel XServe (still running Tiger 10.4.10).

I'll send you the iBook's QRecall log file separately.

-- Bruce

OK, this is a little strange. First, I was able to duplicate the console errors, but not consistently. I was running QRecall while leaving the console log window open. When it happens, it happens just after closing an archive window. Simply opening an archive, and then closing it, was enough to cause it to happen at first. The more I tried to repeat it, however, the less often it happened.

Then I tried to Verify the archive. This is where it gets interesting. As the verify ran, I got about 11 messages in the console log that looked like this:

2008-01-11 18:02:22.224 QRecallHelper[12609] *** Assertion failure in -[DataFile readAtPosition:intoBuffer:length:], /Users/james/Development/Projects/Quantum Recall/Common/Source/File/CarbonFile.m:218

The verify eventually failed, at about 95% on the progress bar, and when I clicked on the warning triangle, I got a dialog suggesting that I consider reindexing or repairing the archive. Instead of doing that, I closed the archive (and did not get a console error that time). Then I re-opened it. and I ran the verify again, and got the same errors. So I closed it (again with no errors, and reindexed it. The reindex apparently succeeded, since I got no errors or warnings, but a subsequent Verify failed just like before.

So I tried a repair, and that failed as well. I don't have much on this server yet, so I'll run a new backup with a new archive. I'll send you the QRecall log file via e-mail.

-- Bruce

James Bucanek wrote:QRecall version 1.0.0(54) should address these issues, and a number of other ones.

I confirm that the new version fixed the problem for me, both on my Xserve and my iMac at home.

-- Bruce

I was just about to report this very problem. It's happening with our new Intel Xserve, running 10.5.1. (We're still setting up the server, so no data is at risk yet.)

At first, actions worked, and then later they didn't. I was able to fix it once by deleting all vestiges of QRecall off the hard drive (including prefs, application support files, etc.) but that didn't work the next time. I did notice that each attempt to run an action resulted in another instance of QRecallHelper being launched. At one point, Activity Monitor showed about a dozen instances running. I used Activity Monitor to quit the extra ones.

I'll send you my log file via e-mail, in case there's anything in there that'll help.

By the way, you'll notice in the log file a bunch of instances of QRecall failing to finish a backup because of disk corruption. This was NOT QRecall's fault! We have a bad external drive enclosure, and the errors were also happening with Time Machine, and even Finder copies.

What was particularly interesting about that was that QRecall would identify the problem DURING the backup, stop, and report the problem immediately. This is exactly what it should do, in my opinion. On the other hand, Time Machine never said a thing. With Time Machine, it was only after I dismounted the drive, and remounted it later, that the Leopard OS would tell me the drive was hosed. It would then send me to Disk Utility, but DU was unable to repair it.

If I had been depending on Time Machine, I might have gone for days without realizing the drive was bad and the Time Machine backups were worthless.

-- Bruce