I've never heard of anyone complaining that QRecall and VMware don't play nicely—and I have quite a few VMware users.

First, make sure you're using QRecall 2.0 (currently in beta, but close to a final release). If your still running into problems, send a diagnostic report.

Alexandre Takacs wrote:Hi

Hello!

Probably a newbie question but I can't seem to find a way to allocate a fixed size - say 1Tb - to my archive a let QR manage it.

Not per se.

You can add a "free space" condition to your merge and compact actions that will only run when the free space on the archive's volume drops below a fixed threshold. The idea is that you let the archive grow as needed. When the volume starts to fill up, the merge and compact actions start to run and begin discarding older items until your free space is above the threshold again. That's actually one of the schemes the capture assistant will set up for you.

If you absolutely have to cap the size of an archive at 1TB, I'd suggest creating a 1TB partition for that archive. QRecall is smart enough to stop capturing when the free space on the volume drops to a critically low level.

There have been a few requests over the years for an "archive size is ..." condition, but it's still on the wish list. I'll give it a +1.

Also compact action is just unworkable with my (consumer grade, admittedly) NAS:

First, make sure you're getting the best performance you can. The compact action does a lot of I/O. If you have multiple computer systems, use the system with the fastest connection to the NAS (preferably wired Ethernet) to do the compact. You'll probably get an order or magnitude better performance over WiFi.

The compact action also performs the bulk of its work incrementally. That means you can stop the compact at any time and start it again the next day and it will, more or less, pick up where it left off.

To automate this, schedule the compact to start every evening (say 9:00 PM) on a computer you don't mind leaving on. In the compact action, add a "stop after X hours" or "stop at XX:XX" condition to stop the compact after it has run for, say, 9 hours. Let that run every night for a week, and you should get caught up.

The need/benefit of compacting an archive is sporadic and infrequent. Once compacted, you probably won't need to compact it again for a month or more (unless you capture and roll over a lot of data). The compact action is smart and won't do much, beyond basic maintenance, most days if the free space in the archive hasn't grown too much.

Bryan Derman has released rev D of his optical media backup script for QRecall 1.x.

Mostly minor bug fixes, but if you're using it you'll want to update.

See the release notes at http://www.derman.com/blogs/QRecall-Backup-Sets.

QRecall 2.0 will be a free upgrade for everyone.

All permanent identities keys will work with QRecall 2.0. So it doesn't matter if you buy a key now, or after 2.0 is released.

There are no plans to charge existing key holders for upgrades in the foreseeable future.

In the interest of full disclosure, there may be future features which require an additional identity key to take advantage of those features. But that would only apply to those new features, in the future...

Erik,

Sorry, but 2.0 is feature complete. It might make it into 2.1 or 2.2.

In the mean time, you might be able to take advantage of QRecall 2.0's ability to set capture preferences for individual items. If the files you want to exclude are relatively static, you could script the command line tool (qrecall) to set the "exclude" capture preference for a group of files matching a filename pattern.

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

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.

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.

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.

Ralph,

Thanks for letting us know. We've been having a horrible time with OS X Server and our secure SSL certificates.

Try it now and see if things are better.

Jan,

I'm guessing you're still using QRecall 1.2.x. That version doesn't work so well on El Capitan (OS X 10.11).

You need to hop on the QRecall 2.0 beta bandwagon.

QRecall 2.0 will want to make some small adjustments to your archive's settings and actions, so if at all possible have all of your QRecall archives mounted and reachable when you launch QRecall 2.0 the first time. (Don't worry if this isn't practical, QRecall will keep trying each time you launch it.)

Jack,

I'm really sorry to hear you've had so much trouble. The sad fact is that QRecall 1.2 is not fully compatible with Yosemite, and exhibits serious bugs on El Capitan.

QRecall 2.0 addresses all of these issues. While technically still in beta (hammering out the last few bugs), it's pretty stable and much more compatible with 10.10 and 10.11. Here's what I'd suggest:

Download and install the latest QRecall 2.0 beta.

Open the archive with 2.0 and restore your Yosemite volume. QRecall 2.0 can transparently read an archive created with 1.2.

Because QRecall 1.2 doesn't completely capture the Yosemite system files correctly, reinstall Yosemite using your Install OS X Yosemite app, over the volume you just restored. This will replace all of your system files with a fresh copy.

That should get you back on your feet. QRecall 2.0 should see a final release candidate in a new few weeks.

No apology necessary. It's a common problem, and I'm still trying to design an interface that makes this situation more obvious.

Thanks for the feedback.

Tim,

I definitely know what your problem is. You're still running QRecall 1.2.3. QRecall 1.2 is not fully compatible with Yosemite (OS X 10.10) and exhibits a number of serious problems in El Capitan (OS X 10.11).

QRecall 2.0 is still in beta, but is stable and very close to a final release. You can jump on the beta bandwagon now if you like (http://www.qrecall.com/download/) or wait until 2.0 is officially released, at which time it will show up and an automatic update for 1.2.

Just be aware that QRecall 1.2 is incapable of correctly capturing a OS X 10.11 system or its applications, although it should do an adequate job of capturing all of your user documents. Everything you have captured with 1.2 can be restored by QRecall 2.0.

Tim,

Sorry to hear you're having trouble. First of all, did you try restoring your actions from your QRecall archive? They're just documents in the ~/Library/Preferences/QRecall/Actions folder. If they just got accidentally removed, that would at least restore them.

I'll look into the problem with the assistant. In the mean time, please send a diagnostic report (Help > Send Report) so I can check other details, like what version of QRecall you're using and so on.