QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: Erik Mueller-Harder
Forum Index » Profile for Erik Mueller-Harder » Messages posted by Erik Mueller-Harder
Author Message
This is an excellent suggestion. #1 sounds perfect. Thank you!
OK, that makes sense.

FYI, my use case for this was for capturing only only recently created or modified files: for this particular situation, I want a small and lean archive and have no need to capture even one copy of “old stuff.” As you have guessed, using a smart folder was a workaround for QRecall not having a way to capture based on such criteria.

For now, perhaps I’ll just have Hazel make Finder-level copies — unless you have a better suggestion?
If I attempt to back up the contents of a Finder-created saved search (smart folder), the search document itself is backed up, but its contents are not.

Is this expected behavior? I’d find it much more useful to be able to back up the files listed within the folder.
Problem solved!
Thank you for the detailed response to Paul, James — and for your problem report, Paul.

I’m on Mojave, too, and while I haven’t had the problem Paul reports, I have had consistent problems with QRecall Monitor reporting that there have been Capture issues with various files in ~/Library and one in ~/Pictures. In each case, the problem is ”Unable to read extended attribute data.”

I’d given QRecall.app and QRecall Monitor.app Full Disk Permissions, but that had no effect. I’ve just now removed those permissions and instead given them to QRecallHelper. I’ll try to post tomorrow with an update.
Perfect! And I now have my new permanent key.

Many thanks!!
Hello, James —

I’m assuming that identity keys purchased today (as an upgrade to a beta identity key, for example) will be fully valid when 2.0 is released, but I’m not seeing anything that explicitly says so.

I’d like to make a purchase, but I wonder whether I should wait for 2.0 to be released.


— Erik
Hello, James —

I’ve searched for information about the ability to filter files for capturing by file extension — in the documentation, the GUI, and on the forum, and found only this thread from ’09. Do you plan for this to be a feature of 2.0? (I hope!)


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!
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.
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
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.

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?]
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.
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.]
Forum Index » Profile for Erik Mueller-Harder » Messages posted by Erik Mueller-Harder
Go to:   
Powered by JForum 2.1.8 © JForum Team