Nicholas Sloan wrote:You will know far more about this than me, but why is it then that other apps (Synk?) seem to have no difficulty in adding multiple power events without interfering with the existing Energy Saver schedule setting?

Most of the well-written utilities (like Power Manager) manage to coexist with Apple's single wake time that you can schedule in the Energy Saver preference pane. They do it by running a daemon process that automatically updates the next auto-wake time as needed. In doing so, they can implement a complex schedule of wake times even though there's only one hardware wake time.

For QRecall set its own wake time, it would have to implement something similar. I'm still not sure how that would interact with other programs, like Power Manager, if both are trying to implement their own schedule. I will, however, set some time aside to research the problem.

Nicholas Sloan wrote:What about unmounting?

Still on the to-do list.

Nicholas Sloan wrote:Am I right in thinking that QRecall can not automount volumes?

QRecall can, and will, automatically mount volumes. There are restrictions imposed by the operating system when mounting volumes while your account is logged out, but if the volume can be mounted QRecall will mount it.

Prion wrote:Did I get this right or should I create one partition just for the minimal OS and store the full system including apps, data etc on another partition?

The idea is that you create a bootable partition by installing a minimal copy of the OS—just enough to boot from—on an external drive. You then install a copy of QRecall to act as your recovery system. You can then create and store your QRecall archive on the same volume, or on a different volume if you prefer. Set up your actions to capture your entire boot volume to the archive on a regular basis.

So the answer is you can use one or two, but you only need one.

The idea is that if anything happens to your main hard drive, you simply boot from the external, open QRecall, open the archive, and restore your system. You don't need to make another bootable copy of your OS or try to keep your emergency OS up-to-date with your system. It exists solely to run QRecall. You don't even have to install an identity key.

There is a caveat: Apple continues to make technological changes in the filesystem. The Tiger (10.4), Leopard (10.5), and now Snow Leopard (10.6) operating systems all depend on new filesystem features. Thus, you must capture and restore a Snow Leopard partition using Snow Leopard. You can't restore a Snow Leopard system using Leopard. Thus, the emergency OS you have installed on your external drive must be at least the same major version as the system you want to restore.

Hello,

QRecall treats packages (or bundles) just as the filesystem does: a folder containing files and other folders. Any package, be it an application or framework, is captured by individually capturing each file contained in the package.

You can explore packages in the QRecall interface. Choose the View > Show Package Contents item from the QRecall menu and the browser will expand the contents of packages allowing you to explore their history. This is approximately equivalent to the Show Package Contents command in the Finder.

Steve,

I don't see much of a pattern. It appears that you've only experienced one crash on this computer. I can see from the logs that you've encountered some I/O errors, but have since repaired the archives.

The one crash occurred during a merge action, which has me even more mystified.

If you have other computers that have experienced QRecallHelper crashes (your initial post indicated that you've had more than one), please send diagnostic reports (Help > Send Report...) from those computers. In the mean time, I'll try to reproduce the problem, or least track down the source of the mystery thread, here.

Steve Mayer wrote:Where/how would I get a diagnostic report?

I'm sorry, I should have explained.

Choose the Help > Send Report... command. It will upload a report to the QRecall server that includes an anonymized system profile, your recent log activity, and any crash reports.

Diagnostic reports help me get a complete picture of whatever problems QRecall is encountering.

Steve Mayer wrote:I seem to be getting sporadic failures in the QRecallHelper/QRecallScheduler area where I'll get the "lost connection to helper" error in my log.

You and me both.

I've been following the trail of an occasional QRecallHelper crash that only occurs in Snow Leopard.

Unfortunately, your crash is different than mine. It occurred in a C++ thread started by Apple's DesktopServices library. I honestly have no idea why such a thread would be running or what it's doing. Apple doesn't document any of the internal functions being executed.

If you can, please send a diagnostic report. That will include all recent crash reports. Maybe there's a pattern.

Steven M. Alper wrote:I'm unable to do a Verify on some archives. It's reported that they need to be reindexed, however when I attempt to reindex the process sits in "Waiting for archive" endlessly.

"Waiting for archive" means that some other process has the archive files open. QRecall won't attempt to update an archive that being written by another process at the same time.

What you need to do is:
(1) Make sure all processes have closed the archive files.
(2) Verify the archive.
(3) If the verify fails, then consider repair/reindex.

You can do (1) using a hammer or a scalpel. The hammer approach is to restart the computer the archive drive is connected to. The scalpel is to find out what processes have those files open and stop them. This might involve turning off file sharing, etc. The Terminal command

sudo lsof '/Volumes/Mercury 1/'

will tell you all of the processes that have any files open on that volume. Quit processes or applications until there are no files in /Volumes/Mercury 1/QRec-G5.quanta that are open. This should be done on the computer that's physically connected to the volume.

Once you've got all of the files closed, run a verify (2). The verify might be able to auto-repair the archive, something it couldn't do while the archive was open.

If the verify reports problems, repair the archive.

Invalid property list
     archive properties not updated
     Path: /Volumes/Mercury 1/QRec-G5.quanta
     File: settings.plist

Same thing when I try to Repair....

I suspect that error will go away when you stop the process that has the archive files open.

Chris Caouette wrote:UPDATE: Problem Solved.

The sample was inconclusive, but the log file you uploaded was full of -36 errors. I'm satisfied that this is the same Airport bug that 1.1.3a6 works around.

I'm glad you were able to resolve the problem, and please post anything else odd that you encounter.

Chris Caouette wrote:Activity monitor was at 0 and I left it overnight. It definitely stops at iPhoto and 1.59GB.

That's definitely "stuck."

A good test would be to perform the same capture, to the same archive, on the same volume, but when it's connected directly to the Mac Pro. If that works, then it seems likely that this is a network/Airport issue.

If you want to help track down the problem, do this:

Let the capture run until it gets stuck.

Open the Activity Monitor.

Find and select the QRecallHelper process (I usually type "QRe" into the search field).

Get the PID number of the process.

Open a window in Terminal.

Issue the following command, replacing PID with the number from Activity Monitor:

sudo sample PID -file ~/Desktop/QRecallHelper.sample.txt

Enter your account password

When it's done, e-mail me the QRecallHelper.sample.txt that's now on your desktop, followed by a diagnostic report (Help > Send Report...).

Chris Caouette wrote:Every time the file gets to iPhoto at 1.59GB it stops.

My first question is "does it really stop?" My second questions is "how long did you wait?"

Some directories contain hundreds, even thousands, of items. This is especially true of folders containing music, pictures, and mail, were the application keeps lots of individual files in one massive folder. This requires QRecall to read and compare hundreds, if not thousands, of file records which in turn require tens of thousands of little reads from the archive.

On a local drive, this can be accomplished pretty quickly. But on some networked file systems this can take orders of magnitude more time. It may seem like the capture is "stuck," when in reality it's simply grinding its way through a bazillion file records.

The way to test this theory is to run an application like Activity Monitor. If the QRecall capture is still working, you should see a steady flurry of small network reads and sends. If you see that, and the CPU usage of QRecall Helper indicates activity, then it's probably still working. BTW, you can use the Activity Monitor to force quit the QRecall Helper process if you need to force an action to stop.

Chris Caouette wrote:I do hourly backups and want to keep the last 24 hours, then those would get merged to a single layer for the day and kept for 14 days.

Create a rolling merge action that:

Keeps most recent 1 day

14 Day layers

After that, what you keep, how often, and how long is up to you.

The "Keep most recent" setting basically ignores any layers created in that time period. So keeping 1 day will leave your last 24 hour's worth of captures alone.[*]

The "14 day layers" create 14 one-day time periods following what you keep. All of the layers within each time period (day) are then merged into a single layer, keeping only the last version of each file.

The logic repeats using successive periods of weeks, months, and years.

PS: I did a test full recovery to a temporary partition and it booted flawlessly!

Always good to know.

[*] Footnote: The rolling merge time periods are always calculated relative to midnight the morning of the day you run the merge (i.e. 00:00:01). So running a merge at 1:00 AM and 11:59 PM has the same effect. It also implies that any captures done between midnight and now are always ignored, since the ignore period always starts at the last midnight.

Gavin Petken wrote:Getting this error as well, after SL upgrade, but only on 1 out of 3 machines

Gavin,

Definitely try 1.1.3a6, at least on the computer that's getting the error. It's fixed the majority of problems with Snow Leopard. If you continue to have problems, send a diagnostic report.

Chris Caouette wrote:Can I restore the Qrecall archive to a new blank drive a be able to boot from it or do I need to install the basic OS first?

Either, as long as you're restoring from the same generation of Mac OS X. Changes in the filesystem make it impossible to restore a Leopard system using Tiger, or a Snow Leopard system using Leopard.

My recommended backup strategy is to install a minimal copy of your current OS on a bootable external drive. Strip off everything you don't need (apps, languages, printers, etc), install QRecall, and then use that drive to store your QRecall archives.

If disaster should strike your startup drive, boot from the external and restore your startup volume.