James,

I think I have some invisible "orphaned" actions, probably as a result of testing various versions of QRecall. All the actions currently defined in my Actions window are configured to run "after volume connects". But when I booted my MacBook Pro for the first time in a week this morning, as soon as I logged in, before I had connected the external backup drive, the QRecall monitor window popped up and told me it was trying to capture. The capture, and, I think, a subsequent compress, didn't run and the error message was something like "archive file not found". (I probably have used several different archive names in my testing.) Sorry I don't have more details, but I was in a hurry to get something else done this morning, so I just dismissed the messages and decided to deal with it later. This is later.

When I did plug the external drive in, then the actions that I expected to run did run and there were no problems with that.

Where would the invisible actions (if that's what they are) be hiding, and how can I get rid of them? I'll send you a report from the latest beta as soon as I send this, so you'll have the log files.

-- Bruce

A better term would be "lingering" actions.

You have five actions defined, all scheduled to run "When archive volume connects," each with a staggered start time (1 minute after archive connects, 2 minutes after archive connects, ...).

Here's what happened.

On August 22 at 16:03:19 you connected the volume named Backup Disk. This triggered the schedule of all five actions:

A Capture was scheduled to run immediately.
A Merge was scheduled to run at 16:04.
A Compact was scheduled to run at 16:05.
A Compact was scheduled to run at 16:06.
A Merge was scheduled to run at 16:07.

All of the actions also have repeat schedules. Once the capture started at 16:03 was finished, it was rescheduled to run again in 24 hours (Aug-23 16:03). Ditto for the remaining actions.

At 16:07 you logged out and shutdown. During the shutdown, the scheduler made a note of all the actions that were currently scheduled to run.

On August 29th you rebooted. The scheduler started up and immediately discovered that it had five actions that were supposed to have been run on August 23rd with various start times between 16:03 and 16:07. The scheduler then started them all immediately.

The perfect storm of events that led up to this were:

- A bunch of actions that were automatically scheduled to run at some distant time in the future.
- A scheduler that was shutdown before the "Backup Disk" volume was unmounted (the scheduler never saw the volume go off-line which would have canceled the repeat schedule)
- The scheduler starts up again long after the previously scheduled actions were supposed to run so that the actions are started immediately.

I'm not saying that it should work this way, but that's what happened. What probably should happen is that the scheduler should assess the state of the mounted volumes first before starting any previously scheduled actions. But there are coding challenges that could make that difficult.

James Bucanek wrote:At 16:07 you logged out and shutdown. During the shutdown, the scheduler made a note of all the actions that were currently scheduled to run.

Yeah, I probably did exit before everything finished on that day.

The perfect storm of events that led up to this were:

- A bunch of actions that were automatically scheduled to run at some distant time in the future.
- A scheduler that was shutdown before the "Backup Disk" volume was unmounted (the scheduler never saw the volume go off-line which would have canceled the repeat schedule)

Sometimes when I shut down, I unmount the external drive first. Sometimes I don't. I can't recall which way I did it last week. My guess is that I shut down without unmounting first, and during shutdown, OS X probably kills running tasks (like QRecall) before it unmounts drives.

I'm not saying that it should work this way, but that's what happened. What probably should happen is that the scheduler should assess the state of the mounted volumes first before starting any previously scheduled actions. But there are coding challenges that could make that difficult.

Thanks for the explanation -- that mostly makes sense. But one thing still confuses me -- the part about the scheduler assessing the state of mounted volumes. When I started up this morning, the external drive WASN'T mounted. It wasn't even plugged in yet.

If I added a "ignore if no archive" condition to each of the actions, would that help?

-- Bruce

Bruce Giles wrote:Thanks for the explanation -- that mostly makes sense. But one thing still confuses me -- the part about the scheduler assessing the state of mounted volumes. When I started up this morning, the external drive WASN'T mounted. It wasn't even plugged in yet.

This is where it gets complicated for the scheduler.

Information about disk and volumes is provided to applications via a series of events that the application can subscribe to. Once an application subscribes, it receives a disk mount event when you plug in a volume and disk unmount event when you eject it.

The action event schedules are driven by these events. When OS X sends a disk mount event, QRecall sees if any actions need to start. When the scheduler receives a disk unmount event, it sees if there are any actions that need to be stopped.

But there are no events associated with volumes that are already mounted (or not mounted, which is the more perverse case) when the application first starts. So some code would have to written to examine the state of the mounted volumes when the scheduler starts and compare that against assumptions about the state of mounted volumes carried over from when the scheduler last shut down.

If I added a "ignore if no archive" condition to each of the actions, would that help?

That will fix the problem. Conditions are evaluated when the action is started, so as soon as the action is started it will check its conditions and skip the action (assuming the volume isn't online).

James Bucanek wrote:

Bruce Giles wrote:If I added a "ignore if no archive" condition to each of the actions, would that help?

That will fix the problem. Conditions are evaluated when the action is started, so as soon as the action is started it will check its conditions and skip the action (assuming the volume isn't online).

OK, I've added that condition, and we'll see how that does. Thanks!

-- Bruce