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.

Charles Watts-Jones wrote:Have followed instructions. All seems fine now.

That's a huge relief.

One very minor point, the Activity Monitor tells me that the next run is 'today' quoting a time that has already passed. Ideally it should say 'tomorrow' in this situation.

It's a known bug in the monitor. In some circumstances it's not updating its display when the schedule changes.

Steven M. Alper wrote:Forgive the obscure YES reference.

I'll have to forgive you, because I don't know the reference.

Verifies are hanging up at the last moment, apparently. I've got one working on a 92 gig quanta. At 33 hours I clicked the X button (no choices appeared). The X button is now greyed out at 42:09:53.

Two questions:

Does it happen consistently?

What version are you running? I made a recent change that would that might affect this. The change would have appeared in 1.0.0(49).

3 processes are waiting. (At 47 hours it'll be 4 processes.)

If it's what I suspect, you're going to have to kill -9 the action process. Either use the Activity Monitor or use the 'kill -9 <pid>' command. (A regular 'kill <pid>' is the same as a cancel, which you've already done.) A 'ps -auxww | fgrep QRecall' command will give you a clue as to which process started first. That's the one you want to kill.

Since this is a verify, there's no possibility of damaging the archive. The other actions will take off as soon as the first one dies.

QRecall 1.0.0(51) is available for download.

Choose QRecall > Check for Update... to update the application. After updating and reauthorizing, you should restart your system.

A late issue with the new scheduler has required a change in how the scheduler tracks volume mount/unmount events. These events are used to run actions that are triggered when a volume is mounted.

The new scheduler now starts a second QRecallScheduler process. This process listens for volume events while the user is logged in. When the user logs out, this process stops.

Note that OS X unmounts all ejectable volumes when a user logs out and mounts them again when the user logs back in. While logged out, volumes are not mounted -- even if they are mounted by another user. If you have actions that are run when a volume mounts, those actions will not run while you are logged out.

After upgrading to 1.0.0(51), it is highly recommended that you restart your system. There are security issues with replacing a running daemon (which will be ironed out in a future version). Restarting allows the scheduler to be started with the correct execution permissions.

A workaround for the volume mount/unmount notification problem has been worked out and is being tested. The solution is actually more robust and consistent than the previous version.

1.0.0(50) is on the alpha feed already. Expect to see it on the beta feed by Saturday.

This is why I hate making changes like this at the last minute.

Installing the Scheduler as a deamon has created a new problem: A race condtion during startup. The framework that the scheduler uses to detect volume mount/unmount events may, or may not, have finished initializing when the scheduler starts. If it hasn't, the scheduler crashes and starts again. This is why the logs are filled with broken socket errors.

I'm working on a solution to this, and a couple of related problems. Stay tuned. A new version should be available very soon.