Charles,

You didn't mention which version of QRecall you are using. If it's 1.2, then restoring a bootable Yosemite volume is dicey. Starting around OS X 10.10.3, Apple started adding a lot of new security requirements that a volume restored with QRecall 1.2 might not satisfy, and it's completely incapable of restoring an El Capitan system.

You did the right thing restoring the volume—boot from an external volume and restore your boot volume. Just make sure that your external volume has the same major version of OS X that you're restoring. It's often the case that an older version of OS X (10.9) will be incapable of restoring a newer version of OS X (10.10), because of new features Apple has added to the filesystem.

OK, so you've restored your boot volume and it doesn't boot. Don't worry. Starting with OS X 10.9, the best remedy is an over-install. After recalling your boot volume, boot into your OS X recovery partition and simply reinstall OS X over what you recalled. OS X is now very good about surgically reinstalling the OS. It won't overwrite any of your accounts, documents, applications, or preferences. When the install is finished, you'll have the latest OS and everything else should be intact.

Now, about capturing Mail. The Mail app uses a database. This is really difficult (read "impossible") to cleanly capture while you have Mail open. The best time to capture your mail is when the Mail app is closed.

If getting a clean capture of your mail is really important, and you're using QRecall 2.0, consider scheduling a capture of your mail folder and preferences "when Mail closes", using the new application-based event schedule. You can also have QRecall skip your hourly capture if the Mail app is open, or just hold until the Mail app closes. But if you're like me and leave your mail app open all day, that won't be of much help.

Ralph,

Don't worry. You're the unfortunate victim of the unfinished action that was adding error correction codes to the archive. Nothing you've done has made any changes, or endangered, the data in your primary data file.

Here's what happened. The action to add error correction codes to your archive crashed (or was terminated during the reboot). The correction code files are now incomplete. When you tried to reindex the archive, QRecall—in the interest of full disclosure—started logging every missing checksum and error correction block it found, or didn't find in this case.

That caused your log to explode. When you opened the QRecall app, you probably had the log window open. QRecall started reading the gigabytes worth of new log messages into memory. This began to eat up all of you memory and drag your system into the mud.

Here's how to get out of this mess:

First, get rid of the bloated log file. Open your ~/Library/Logs/QRecall folder and trash anything that looks too big. That's probably just going to be your primary QRecall.log file, unless you rotate log files daily.

Select your archive in the Finder. Control/Right-click on the archive and choose Show Package Contents. Inside the archive you're going to find a repository.data file. You'll also see a bunch of "companion" files with funny names like this:

repository_8k.checksum32
repository_p8w8k16m2.0.anvin_reed_sol
repository_p8w8k16m2.0_8k.checksum32
repository_p8w8k16m2.1.anvin_reed_sol
repository_p8w8k16m2.1_8k.checksum32

Trash all of these "companion" files. (Do not trash your repositoy.data file. That's where all of your data lives!)

Launch QRecall. Choose File > Repair Archive…, choose your archive, select Reindex, and Bob's your uncle.

Ralph Strauch wrote:I just tried to backup to my second archive, the one where I had the problem installing Error Correction. Qrecall now tells me that that archive needs reindexing, so I've just started a repair.

According to the log you sent me, the capture action completed but it looks like the error correction change was still running when your restarted your computer. A reindex should fix it.

Qrecall Monitor is showing Idle, while Qrecall is showing the repair in progress. I don't remember if that's standard, or not.

That's normal. Actions that modify an archive run in the archive browser window, if that's where you started it.

Ralph Strauch wrote:As I was doing this I found most of the other apps I was running had also frozen and I ended up doing a hard power down reset. I don't know whether Qrecall was the cause of all of this, or it was just coincidental.

I'm not aware of anyway that QRecall could cause your other apps to hang, so I'm going to go with "coincidence."

Ralph Strauch wrote:(Activity Monitor shows Qrecall as "not responding" and shows three instances of Qrecall Helper running, two active and one inactive. I don't want to force quit quit while the backup is running, but once it finishes I'll restart qrecall and send you a report.

It sounds like both actions might still be running. A capture runs as two instances of QRecallHelper (one to perform the capture and a second to gather user-centric metadata; the latter is usually not very busy), and the error correction task runs a single instance. So my advice is to let them run. Eventually the QRecallHelper processes will run their course and you can check the log for success, failure, or incompleteness.

Why the QRecall app itself it hung is a mystery. If you have the Activity monitor open and QRecall is still "not responding" take a sample of it and email it to me, if you have the time.

Question: Once I get this computer backed up to both archives I have a second computer to back up to both as well. Should that computer, as well, have both drives mounted when I run v2 for the first time?

It's easiest if your archive are all reachable when QRecall 2.0 is run for the first time, but it is certainly not a requirement. You can easily make these updates yourself at anytime. Here's what the "upgrade" process consists of, in a nutshell:

Replace the legacy alias structure in the action document with a modern URL bookmark. You can do this by opening each action, reselecting the archive, and saving it again.

Move any excluded items from the archive's capture action to the archive's settings. To do this yourself, simply open the archive and edit its settings to set the you items want excluded.

Move any ignored items from the archive's capture action and turn them into capture preferences for that item. To do that yourself, choose the items you want ignored in the Finder and use the new QRecall Capture Preferences service.

Finally, aliases can be finicky. Even if you let QRecall perform the 2.0 upgrade, you might have better success with your rotating set of archives if you manually open their actions, reselect the archive, and save them again. That way, you'll know QRecall is storing the correct bookmark for each archive.

Bruce Giles wrote:The standard Apple crash reporter dialog came up and I submitted it. Does Apple share any of that info with developers, or do they just use it to fix problems in their own software?

Apple shares some crash data with iOS developers, but not OS X developers. Fortunately, the crash logs are also written to ~/Library/Logs/DiagnosticReports/, and when you submit a diagnostic report in QRecall it uploads a copy of any QRecall related crash logs it finds there.

I probably did immediately re-launch QRecall and re-open the archive. If something like this should happen again (and it hasn't, so far), is there anything I can do short of rebooting to force the archive closed?

Rebooting won't have any affect on this problem.

If you have an action that's stuck "waiting to acquire access" and you are absolutely sure that the archive is not being accessed by another process, you can (a) wait 10 minutes for the arbitration logic to do its thing or (b) impatiently open the archive package and delete any invisible .lock, .shared, and .semaphore files you find:

rm /Path/To/Archive.quanta/.[ls]*

The action trying to gain access to the archive will then proceed immediately.

First, try restarting your system.

The scheduler installation is in two steps. The first defines and installs the scheduler service, and the second starts the scheduler. For some reason, the scheduler doesn't always start in OX X 10.10/10.11, or the old scheduler doesn't get stopped. Restarting will force the later to stop and should start up the former.

Whether this is successful or not, please send a diagnostic report so I can review what happened.

First, the bad news: QRecall 1.2 is not compatible with El Capitan.

The good news is that QRecall 2.0 is compatible and it has a ton of new and powerful features. The less than good news is that QRecall 2.0 hasn't been released yet.

But don't worry, QRecall 2.0 is just around the corner and you can get the beta version today. The beta version is now very stable and is nearing a final release?what's left is mostly cleanup and documentation. If you've already updated to El Capitan, you should really download the beta version and start using it.

Here's the short course on moving to QRecall 2.0:

Download the latest beta.

QRecall will first update your actions. It's best to have all of your archives on-line and reachable before installing.

Hold your scheduled actions and wait for any running actions to finish.

Open the downloaded disk image and run the Install QRecall application.

Excluded items are now a setting in the archive, not the capture action. The excluded and ignored items you have set in your capture actions will be transferred to your archive settings. (This is why the archive needs to be accessible.)

Archives created or modified with QRecall 2.0 are not compatible with QRecall 1.2. Once you have modified an archive with 2.0, QRecall 1.x will not be able to use it. (That's why you want to suspend your scheduled actions, as you might want to modify or disable some actions?possibly duplicating some archives?before you let QRecall 2.0 actions start running.)

You can browse, recall from, and verify a 1.2 archive using QRecall 2.0 without affecting its compatibility.

Review the release notes for QRecall 2.0. Detailed notes about upgrading, and most of the major new features, are explained in the release notes for 2.0.0b6.

Keep an eye out for the final release of QRecall 2.0, and please send diagnostic reports (Help > Send Report) with any problems you encounter.

Thanks for supporting QRecall!

David Ramsey wrote:Last question: will simply trying to restore data from this archive with QRecall 2 render the archive unusable by earlier versions? Or am I safe as long as I don't actually store more data into the archive?

You can continue to use the archive with versions of QRecall prior to 2.0 as long as you don't do anything to modify the archive using QRecall 2.0. This includes capturing, merging, compacting, or repairing the archive. Once you do this, the archive can't be opened in QRecall 1.2.

Browsing, recalling, and verifying the archive with version 2.0 will not change it's compatibility.

David Ramsey wrote:I assume that since I am trying to restore from a new installation, my user ID is different. Wouldn't think I'd need write permission to open an archive, but there you go. I'm reluctant to start mucking with the permissions on the file, especially since I see it has extended permissions. What's my next step?

I don't know if your UID is different or not, but you'll need read and write access to that entire archive package to effectively use QRecall. When you open a legacy (1.2) archive for the first time, QRecall 2.0 will need to make some changes. I suspect this is what's causing the permissions error. Send a diagnostic report if you want me to look into it.

Short answer: if you want to use this archive, you will need to make sure the user with QRecall installed owns it. Usually I recommend placing QRecall archives on a volume that has ownership and permissions turned off, especially if you plan to use the same archive with multiple users. It just simplifies the whole permissions thing.

Bruce Giles wrote:

James Bucanek wrote:If you haven't done so, please send a diagnostic report. I'm still looking for combinations of actions the leave the .lock file locked.

Just now sent a report.

I figured out what caused your archive to get "locked" up. You had the archive open in a browser window when your QRecall app crashed.

I was able to use the crash log to figure out why it crashed, and fix that problem. But the result is that the archive was still in "shared-read" mode, thinking it was still open in an archive browser.

You didn't notice it immediately because you probably reopened the archive again as soon as you relaunched the QRecall app. This wasn't a problem because any number of processes can share "shared-read" access. (This is why you can browse an archive while simultaneously recalling from it.) The delete action, however, has to first ensure that all processes with shared-read access have closed the archive and relinquished it.

So, this is expected behavior. If you have the archive open for any reason (browsing, verify, recall, capture, ...) and that process crashes, the next process that wants use it has to go through the arbitration procedure to reestablish access to it.

Ralph,

That's a great idea. I'll draft something soon.

David,

My bad. I failed technical support 101 and forgot to ask you what version of QRecall you were running.

QRecall 1.2 is not compatible with El Capitan. It sort of runs, but changes in the OS X 10.11 filesystem and security policies mean that it is incapable of correctly restoring system files and some applications.

If you're still running QRecall 1.2, you need to jump on the QRecall 2.0 beta. Most of the major new features, along with notes on upgrading from 1.2 to 2.0, are described in the release notes for QRecall 2.0.0b6.

The beta is quite stable at this point, and rapidly approaching a final release. I only have 23 items left on my "must fix before release" list.

Paul,

All great suggestions. I'm writing them down, although technical issues might limit a few of them.

The lack of good full-screen support in QRecall is my fault. The only time I "use" full-screen mode is when I accidentally set it off, and then I spend the next minute cursing the name of whoever came up with such a useless and frustrating interface mode while I stumble around trying to remember how to get out of it.

But then I hear from users who love it, so clearly my opinion is not the overwhelming majority of users.

I'll try to get QRecall 2.1 to play nicer in full-screen mode.

Kenneth,

That's a great suggestion, but I have a couple of other ideas. Just deciding whether I want to try one today or wait until the Great UI redesign planned for QRecall 2.1.