I do plan to add encryption to QRecall (all of the archive data structures are in place to support it, it's just a matter of implementing it).

In the meantime, you might try placing your QRecall archive in an encrypted disk image. I haven't tried that here, but I think it should work.

Bruce Giles wrote:So the full volume restore worked, but it seemed a little like swatting flies with an atom bomb. Was there a better way to do this and just restore whatever files had been changed since the last capture? Or is that actually what the full volume restore did?

Restore is a "smart" atom bomb.

A Restore only recalls/replaces files that are different than the captured version in the archive.

QRecall compares the file information (size, attributes, modification dates, etc.) against the same item in the archive. If they are identical, QRecall assumes the file hasn't changed and doesn't need to be recalled. This is the same test used to determine if the file has changed during a capture.

Eric Oshlo wrote:Obviously, Qrecall has caught my eye; however, I haven't figured out whether it can perform in the same fashion as Retrospect with respect to automatically backing up the laptops when they are connected to our home network with out the need to manually mount the laptop volume on the server machine or vice versa manually mounting the server volume on each laptop.

QRecall will automatically mount a network volume that contains the action's archive, as long as these conditions are met:

- The user is logged in when the action starts. (The operating system does not permit network volumes to be mounted when you are logged out)

- You've saved the user name and password for the volume on your keychain. If you haven't, QRecall will prompt for the network volume's user name and password when the action runs.

Please be aware that there are still problems with QRecall and Leopard. The issue centers around the Leopard security model; it prevent the scheduler from communicating with the actions that have been started. This results in "Action could not be started/cannot establish a connection with helper" errors in the log and essentially prevents QRecall from running any actions.

The problem is oddly inconsistent. Some users are running Leopard without incident, for others the problem appears after a restart, while others can't get QRecall to work at all.

I've made a lot of progress towards solving this problem and have a conference call with the Apple engineers today to resolve the remaining issues.

An update should be available by the end of the week.

Several users have reported an issue where actions won't start following an upgrade to 1.0.0(53). The problem seems to be that Leopard doesn't like the upgrade process replacing the scheduler on-the-fly.

It appears that the problem can be fixed by uninstalling and reinstalling the scheduler. Open the QRecall > Preferences... and switch to the Authorization panel. Uncheck the "Start and run actions while logged out" option. Count to 10. Check it again.

This should uninstall, then reinstall, the scheduler. If that doesn't immediately solve the problem, try restarting. Please report any problems you encounter after following this procedure.

That's so cool!

Seriously, I have no idea why this is happening. Sometimes you get the huge icons and sometimes you get the regular ones. The size seems to persist until you close and reopen the Quick Start window.

It appears to be a Leopard issue. I can't get any of my Tiger machines to do this.

Bruce Giles wrote:Confirmed.

That's good to hear.

QRecall launches *extremely* quickly now. ... (To be fair, I've been running it on an Intel Mac for only a couple of weeks, and most of that was automatic schedules, so I hadn't spent a lot of time actually launching QRecall or opening archives.)

The scheduler management logic is much cleaner now; the client application spends almost no time during start up making sure things are in order.

The major speed improvements in opening archives was rolled into 1.0.0(49), so maybe you just hadn't noticed yet.

QRecall 1.0.0(53) resolves this issue.

Upgrade to 1.0.0(53) using the QRecall > Check for updates... command.

Clearly, you've turn on the firewall.

Leopard is confused. I have no idea why it thinks QRecall implements any network services. This version of QRecall doesn't creating any incoming TCP sockets.

The only network communications at the moment is via the Sparkle framework that checks for version updates. Sparkle works over HTTP (port 80) and doesn't require any incoming access.

So in the end, it doesn't matter if you answer Deny or Allow, QRecall should work just fine. I'm trying to find out why Leopard thinks QRecall accepts network connections and how to get it to stop asking silly questions.

Has the system been restarted since you upgraded QRecall?

During an upgrade, a new scheduler is installed and started using the launchctl tool. Apparently, replacing a running daemon with a new one incurs Mach port permissions issues that I've yet to understand. After a system restart, the daemon is restarted with the correct port permission and this problem goes away. At least, that the pattern I see here.

OS X unmounts all ejectable volumes when you log out. So any action that use an archive on an external drive won't run while you're logged out.

I'm currently looking in to what it would take to remount a volume on an external drive when an action runs.

Note that this would work only with locally connected external drives. Network volumes can't be remounted while logged out because the network server needs a user ID and password to connect; This requires either access to a user interface or your keychain, neither of which are available when you're logged out.

Charles Watts-Jones wrote:this prompts me to ask whether it is possible to script QRecall so that it closes down another programme before running and, even better, will relaunch it after.

That's a feature I've considered adding. Let me throw out two other features I have on the drawing board and let me know if those might also meet your needs.

One is an Application launch/close event that could trigger an action when an application is launched or quit. You could use this to create an action that would backup your mail database whenever you close your mail application.

The other is a some scripting support that would allow you to perform captures from AppleScript or a shell script. So instead of QRecall driving the process, you could have a script drive QRecall performing whatever actions it needed to before and/or after the capture.

Hello Mic,

While I'm thrilled to hear that QRecall is working for you again, I'm still very much interested in investigating your earlier problem. I'm convinced that the errors you were seeing shouldn't have happened, even on a botched installation. Could you tell me a little about how the previous version of Leopard was installed? It might help me reproduce the problem here.

Steven M. Alper wrote:

James Bucanek wrote:
I'll have to forgive you, because I don't know the reference. :?

Ah, well, that will be remedied....

And it was! Awesome. Thank you.

Killt it, using Activity Monitor. I guessed right. But the other processes did not leave waiting state. I had to cancel the compact (of the quanta that could not complete the verify) since there were no other options, reschedule the capture that was next and cancel the merge that followed that (again, no other options available).

You might have had to wait awhile. When an action's process simply disappears, it will take several minutes before the scheduler will realize that it's died and update the queue of waiting actions. But there's certainly no harm in what you did.

After the rescheduled capture began, I launched QRecall to check my version and was notified of b(50).

I hope you meant b(51).

In the interest of beta testing I allowed the update and install to occur while the capture was ongoing. I was going to ask if there were any ill affects I should anticipate, but the capture just finished successfully (after about 42 minutes).

It won't affect any running actions. The only potential complication that I'm aware of is if there were other actions waiting on the one that's running. After the upgrade and scheduler restart, the other actions can be left waiting indefinitely and would have to be manually canceled -- very much like the situation you just went through.

I'd very much like to see your log files. The easiest way to send those is to select the QRecall folder in your ~/Library/Log folder in the Finder, choose File > Create Archive, then send the resulting .zip file to me.

This sounds very similar to a problem reported last week by Frédéric Thomas. That problem only occurs on Mac OS X Server, so these both seem related to specific versions of the operating system.