When I try to capture data from a network-mounted ?client? computer into a new, empty, local archive file on a ?server? computer with a 2.0 beta identity key, I see this message:

Capture requires an identity key
The identity key is missing or invalid. Enter a valid identity
key in the QRecall preferences.

But QRecall, running on the server, reports that the key status is:

Valid beta test key. This key will expire in about 57 days.

When I set things up the other way around (using QRecall to capture local files to a new, empty archive on a network-mounted remote drive), everything works fine.

I?m new to QRecall, so I?m unsure as to whether this is a beta bug or something that I?m doing incorrectly. A client-server approach is supported in QR, isn?t it?

[Addendum: I have, of course, tried quitting and re-launching QRecall, and I have also re-entered the beta test key several times.]

I mis-analyzed this; I apologize.

It seems now that anywhere I try to use this beta identity key that is ?good for about 56 days? anywhere other than the initial machine that I used it with, I?m told it?s invalid when I try to do a capture.

I?ll see if I can find anything further to read up on about identity keys.

Erik,

Make sure you're using the current version of the beta and the beta identity key was issued for that beta.

A beta identity key is only valid for the matching beta version of the QRecall application it was issued for. For example, a beta key issued for the QRecall 1.2 beta will not work with the 1.1 or 2.0 betas, nor will it work with any released version of QRecall.

Your QRecall account page (https://secure.qrecall.com/account.jsp) lists the beta keys you were issued. Each beta key indicates which version it is valid for.

James,

Thank you ? and I?m sorry for taking up your time; I should have been able to figure this out.

I had misunderstood completely! I had thought that the beta keys were good for (approximately) the time specified, or until the end of the beta cycle, whichever came first.

I?m still running b32 on the machine I originally set up, and so the key is still working there. (I update each of my computers? software weekly, and it?s not that machine?s time yet.) Today?s experiments have been with other machines and with b33; hence the discrepancy.

Thanks for the clarification!

[On another note, what is the best mechanism with which to submit minor beta feedback; e.g., UI glitches or ?Help? typos?]

Hmm. That wasn?t it.

1. The server machine that I was originally trying this on was still running ß32, and I was (attempting to) use a ß32 key with it.

2. I?ve updated that to ß33, generated a new key, put it into place in the preferences (it still says it should be good for about 57 days), and am seeing the same problem:

Capture requires an identity key
The identity key is missing or invalid. Enter a valid identity
key in the QRecall preferences.

At this point, I?m utterly mystified. And a little depressed, as QRecall had looked like absolutely what I was looking for.

Erik Mueller-Harder wrote:I had misunderstood completely! I had thought that the beta keys were good for (approximately) the time specified, or until the end of the beta cycle, whichever came first.

Very close. A beta key is valid for the range of versions being tested, and those individual versions each expire on a particular date (listed in the release notes for that version). For example, a v2.0 beta key will work with all 2.0.x(x) beta versions. If you're running version 2.0.0(33) beta it will expire on April 1. If you're running version 2.0.0(19) beta, it has already expired (October 29, 2015).

I?m still running b32 on the machine I originally set up, and so the key is still working there. (I update each of my computers? software weekly, and it?s not that machine?s time yet.) Today?s experiments have been with other machines and with b33; hence the discrepancy.

Beta keys can be used with all beta versions with the same major and minor version number. Your current key will still be valid for all beta versions of QRecall between 2.0.0(29) beta and 2.0.0(33) beta. Earlier versions of the beta have already expired.

So if there's a problem on one machine, I suspect that you're using a different key (one issued for an ealier beta test), the version of QRecall is actually 2.0.0(26) or earlier, or the system date of your computer is wrong (in the future).

On another note, what is the best mechanism with which to submit minor beta feedback; e.g., UI glitches or ?Help? typos?

Whatever method you find easiest. You can send a diagnostic report, post something to the forum, or just fire off a note to support@qrecall.com.

I wouldn't worry too much about reporting anything that's wrong with the help, as it's is currently being rewritten for 2.0.

I?ve sussed it ? and have replicated both the problem and the solution on three different computers.

With QR 2.0ß32 and with 2.0ß33, at least, do the following without an identity key installed:

1. Create a new archive.
2. Create a capture action which will save files to the new archive.
3. Attempt to run the capture action.

QR will then tell you (and very reasonably, too!) that you need a valid identity key.

4. Get a valid identity key. (In testing, I used both ß32 and ß33 keys.)
5. Enter the identity key in the QR preferences.
6. Again try to run the capture action.

Surprisingly, one then sees the same warning one saw after step #3:

Capture requires an identity key
The identity key is missing or invalid. Enter a valid identity
key in the QRecall preferences.

At this point, the only way I?ve found to proceed is to:

7. Quit QRecall.
8. Quit its ?monitor? and ?schedule? processes via Activity Monitor.
9. Move all QRecall files to the trash & empty the trash (include System files in the Spotlight search to find everything).
10. Reboot.
11. Install QRecall.
12. Add the identity key in preferences.
13. Then resume with step #1 above.

Sorry to report the bug ? but very happy to prove that it wasn?t my imagination!

This is all with OS X 10.11.3, running on a 2009 MacBook Pro, a 2009 Mac Mini, and a 2011 Mac Mini, with source files and destination archives set up in various combinations of pushing over a network, pulling over a network, and backing up locally. 100% consistent.

Now that I?ve worked this out, I?ll resume exploring this very fine program....

------

I?ve changed the subject of the first post here from Identity key ?invalid? for backing up networked volume to a local archive? to Causing QR to prompt for an identity key renders it incapable of using a newly entered key

Erik,

Thanks for taking the time to reproduce this.

I suspect that you're running into an issue with OS X. Starting around OS X 10.9, Apple switched to a controlled method for managing access to preference files. Access and updates are now controlled by a daemon named cfprefsd.

While generally a good idea, cfprefsd can sometimes get "stuck" updating a preferences file. What can happen is that you enter your identity key in the QRecall app, and then run another action (like capture) and that action complains that you don't have a valid identity key.

The problem is that the requested change to your preferences file made by the QRecall app (setting your identity key) is "stuck" and it could take a long time before the change gets made. Meanwhile, any action that tries to read your identity key gets the copy from the old value that is still on disk.

Eventually cfprefsd will update your preferences file and everything will work, but for a period of time in between it will mysteriously not.

Deleting all of your com.qrecall.* files in ~/Library/Preferences and/or restarting your system will also clear the logjam.

This is enlightening, James, thank you.

I have, in fact, noticed occasionally that `cfprefsd` (would that be ?Core Foundation Preferences Daemon,? perhaps?) runs away with the CPU ? and that nothing seems to fix it other than a reboot. Despite the age of these computers (two ?09s and an ?11), there?s nothing crufty about their systems: in each case, 10.11.3 has been installed cleanly on an empty drive; they?re running with new user accounts and newly installed apps ? so no massive prefs folders filled with years? worth of garbage! And even so, this is biting me. Sigh.

(Oh, and FYI, I?ve seen no sign of a run-away `cfprefsd` process through today?s QR testing; I?m sure you?re right ? but there?s no other indication of a problem.)

You suggested:

Deleting all of your com.qrecall.* files in ~/Library/Preferences and/or restarting your system will also clear the logjam.

Simply deleting the files does not, in fact, do the trick. Deleting the files and not rebooting ? even with allowing more than a half hour ? has no effect.

It had not occurred to me to test a simple reboot without deleting all the relevant files. I will test this if I end up in the same situation again.

Erik,

Thanks for the additional information.

cfprefsd (and yes, that stands for exactly what you think it does), can also simply get "stuck" updating a preferences file. Technically, it's a deadlock, and it is not always associated with a runaway cfprefsd process.

You'll notice that most of the preferences files have companions; the file com.qrecall.monitor.plist might have a file named com.qrecall.monitor.plist.CY0h1bN. These are temporary copies, waiting to be swapped out. Sometimes the semaphore managed by cfprefsd get orphaned, the preferences file it controls becomes deadlocked, and a stale temp file is left behind.

I suspect (hope) that cfrefsd will eventually break these stale semaphores and resume normal operations, but I've been too impatient to find out and usually just end up restarting my system to resolve it. I'll also, occasionally, delete these old temp copies (since cfprefsd never seems to clean up after itself).

James,

I have confirmed your `cfprefsd` theory, working on a fourth Mac (a little less ancient than the others ? a MacBook Pro from 2013, also running 10.11.3, although this one has been upgraded from 10.9 through 10.10)

I recreated the situation, entered the key in the preferences, and waited several hours. The QR subprocess was still unaware of the key.

I killed the `cfprefsd` process (both the user?s and the root?s; I should have tried one at a time, but didn?t).

I was immediately able to run the capture action. Huzzah!

So I guess the real question is: why is this such a consistent problem on four different Macs? I?m certainly aware of the occasional odd preference not sticking, but nothing so consistent.

Anyway, I?ve learned a lot and have an acceptable work-around. Thanks very much for your help!