Authorization bug returns in b38

James,

With b38, I'm seeing the return of a bug I thought you had squashed. After installing it, on two different systems, I got the dialog asking me about pre-authorizing. (Sorry, I didn't write down the exact words.) I clicked the button to indicate I wanted to do that, and next I was prompted for my username and password, as expected. But when I went to Authorization section of the preferences, on both systems, the checkbox was checked, but the button said "Preauthorize...", not "Cancel Preauthorization". I clicked the "Preauthorize..." button, and it immediately switched to "Cancel Preauthorization", without asking for username and password again (since this was only a few seconds after I had entered my username and password the first time).

After seeing this on the first system, before I did the beta update on the second system, I double-checked to make sure it was preauthorized first, and it was.

I didn't try to do a capture before correcting the preference, so I don't know if it was purely a cosmetic issue, or if doing the update really did cancel the preauthorization.

-- Bruce

Bruce Giles wrote:With b38, I'm seeing the return of a bug I thought you had squashed.

Not squashed, just semi-random. I have not addressed this bug because I plan to replace it with a different mechanism soon.

I didn't try to do a capture before correcting the preference, so I don't know if it was purely a cosmetic issue, ...

It's purely cosmetic. If you had quit QRecall and relaunched it, I'll wager a dozen Krispy Kreme doughnuts that the window would say that it was now pre-authorized.

When you clicked the "Pre-Authorize" button, it launches a process to permanently authorize the helper tool. This normally involves prompting you for your authorization. It didn't because it was already pre-authorized, so it essentially did nothing and then updated the display.

James Bucanek wrote:

Bruce Giles wrote:With b38, I'm seeing the return of a bug I thought you had squashed.

Not squashed, just semi-random. I have not addressed this bug because I plan to replace it with a different mechanism soon.

OK, I hadn't seen it in a while, so I assumed it was fixed. Anyway, it's obviously pretty minor, and I'll wait to see what you come up with.

By the way, I thought I read something in the update description about being able to set the RAM that QRecall uses, which I wanted to do on one of my computers that usually has a virtual machine loaded. But I can't find anything in the user interface to do this, and I can't get to the update description any more either. Did I mis-remember, or is it just hiding, or what?

-- Bruce

Bruce,

Yes, there's a new advanced setting that will let you "trick" QRecall into thinking your system has a different amount of physical RAM than it's actually equipped with. Set it with the defaults command in the terminal. For example, to have QRecall size its memory usage to 2GB of RAM, use this command:

defaults write com.qrecall.client QRPhysicalMemoryMB -integer 2048

Note that QRecall will ignore any setting smaller than 512MB or larger than 6GB.

James Bucanek wrote:
defaults write com.qrecall.client QRPhysicalMemoryMB -integer 2048
Note that QRecall will ignore any setting smaller than 512MB or larger than 6GB.

Thanks, James. I just made the change, so we'll see how it does.

Earlier today, I started a new archive on the MB Pro, and the first full backup under b38 ran without error and verified perfectly. It was pretty fast, too, in spite of having all the archive settings set to "slower, smaller".

-- Bruce