James,

I hate to throw a show-stopper at you now, but I've discovered a problem. If an archive's settings are set to the "slower, smaller" side (all three of the settings), then whenever I try to delete an item from the archive, it fails and I get a message that the archive is damaged. The repair appears to succeed, but every time I try to delete another item, the same kind of failure occurs.

If the archive's settings are all set to the "faster, larger" side, the problem does not occur. However, if I then, after a capture, change the settings to "slower, smaller" and compress the archive, then subsequent attempts to delete items from the archive will fail.

I sent you a report after numerous tests. In the tests, the archive called "Test 1" was initially set to "faster, larger" (the default), while the archive called "Test 2" was initially set to "slower, smaller". You'll see that item deletions from Test 1 succeeded every time, until I changed the settings and compressed the archive, after which they failed every time. Item deletions from Test 2 failed every time.

Bruce Giles wrote:I hate to throw a show-stopper at you now, ...

It's better than releasing a product with bugs.

If an archive's settings are set to the "slower, smaller" side (all three of the settings), then whenever I try to delete an item from the archive, it fails and I get a message that the archive is damaged.

Bruce, you are a genius!

The release was already held up because I have one user who's archive occasionally gets damaged during a merge. So far the problem would only occur about once every three weeks and I had yet to reproduce the problem here. QRecall reports the same failure as the one in your logs. If the problem is related to compression, I should be able to reproduce and fix both.

If you ever want to quit that high-paying government job and work as a full time QRecall tester, just let me know.

James Bucanek wrote:Bruce, you are a genius!

Well, yeah, I know.

The release was already held up because I have one user who's archive occasionally gets damaged during a merge. So far the problem would only occur about once every three weeks and I had yet to reproduce the problem here. QRecall reports the same failure as the one in your logs. If the problem is related to compression, I should be able to reproduce and fix both.

Cool. I hadn't been changing the default compression level for quite some time, but I decided to try a new backup from scratch with the rc, and for some reason, I decided to change the compression level before I started. Everything seemed to be fine until I tried to delete an item.

If you ever want to quit that high-paying government job and work as a full time QRecall tester, just let me know.

Actually, I'm in private industry these days, but if you can match the salary, just let me know!

Bruce Giles wrote:I hadn't been changing the default compression level for quite some time, but I decided to try a new backup from scratch with the rc, and for some reason, I decided to change the compression level before I started.

Well, it's a good thing you did or it might have taken a lot longer to figure this one out.

Version 1.1.0b36 should fix this problem. To install and test b36:

- Download the 1.1.0b36 disk image. Open the disk image to mount it.
- Open your Applications folder and locate the old QRecall.
- Drag the old QRecall application to the Trash. Do not attempt to empty the Trash.
- Drag the new QRecall application into your Applications folder.
- Open the new QRecall application in your Applications folder.
- You can now empty your Trash.

James Bucanek wrote:Version 1.1.0b36 should fix this problem.

I only had time for a few quick tests tonight, but it does seem to have fixed the problem. Everything I tried worked perfectly. I was unable to duplicate any of the problems I had before. I'm going to let it do a full, new backup tonight, and I'll do some more extensive tests tomorrow evening and report back.

I really do like the capability to delete items. It comes in handy when I do something like forget to tell QRecall not to back up my podcasts folder, which contains multiple gigabytes of audio and video files that change daily, and don't really need to be backed up.

This is just confirming that the problem is fixed. As far as I can tell, deletions are working just fine, no matter what the compression level.

This fix, along with a few other minor changes, have been rolled into release candidate 2. Launch QRecall (or choose QRecall > Check for updates...) to get the new version.

James Bucanek wrote:This fix, along with a few other minor changes, have been rolled into release candidate 2. Launch QRecall (or choose QRecall > Check for updates...) to get the new version.

I've tried the latest rc on two different Macs now. So far, I haven't run into any problems at all on either of them.

Thanks for the confirmation, Bruce.

I'll be out of town next week. When I return, it looks like rc2 will become QRecall 1.1.

Thanks again to all my beta testers for your help and feedback. I couldn't have done this without you.