Gary,

I've spent some time investigating, and I have yet to reproduce the problem here.

From your log files, it looks like your activity monitor process gets launched when you log it (which it should), but for some unexplainable reason none of the other processes can communicate with it. So when you start actions, they don't appear in the activity monitor window.

In the example you posted, you later launched the QRecall application. One of the first things the application does is try to establish a connection with the activity monitor process. When that failed, it restarted and reinstalled the monitor (on the assumption that it wasn't properly installed), at which point the monitor process started to receive notifications and generally behaved itself.

Let's try uninstalling and reinstalling QRecall to see if that makes any difference. Launch QRecall. Holding down the Option+Shift keys, choose the QRecall > Quit and Uninstall command. Wait a few seconds and launch QRecall again. After re-authorizing it, see if the problem comes back.

I love my beta testers. I get the best bug reports, ever.

First, please send a diagnostic report. This will tell me a lot more about which processes were running and what action notifications were sent, what settings you're using, and so on.

Good to know, and thanks for the follow up.

Gary,

I can see that it's not working, but I can't see why. (I'm not seeing the problem here, and my system is configured the same as yours.)

There's obviously something a little strange going on. During the QRecall upgrade, both the scheduler and monitor processes were replaced. But for some reason, the monitor stopped and didn't restart again until later. When it did finally start, the notifications it's supposed to receive when an action starts are never delivered.

Try restarting your entire system again (don't just log out and back in) and see if that makes any difference. Also look in the Console application and see if there are any messages from, or about, QRecall logged around 10:07.

Gary K. Griffey wrote:I guess you ran into more issues?

Several, but most have been dealt with.

QRecall 1.2.0(54) beta is now available.

James Bucanek wrote:This weekend, I swear!

I'm sure it's still the weekend ... somewhere.

Gary K. Griffey wrote:Any timeframe on the new beta release that you mentioned in this thread?

Ah, the plans of mice and men.

I originally planned to have the next beta release out over a week ago, but I ran into complications reworking a critical section of the code that captures a file's metadata, that I would really like to release. To slow things down even more, I was attending Audodesk University this week and just today got back to development.

So to answer your question: This weekend, I swear!

Charles,

Log items with a little question mark or a small blue "i" indicate events that are "curious" or merely "minutia". Curious events are logged to indicate something unusual, or unexpected, happened, but are not considered to be a "failure" or even a "warning" that something serious has occurred. Minutia messages are small details that might be of interest to someone, but aren't usually.

Now you might think that almost anything that prevents an item from being fully captured would be serious, but it's not. There are a number of complications that QRecall does not consider critical.

For example, file metadata is nice to have, because it allows QRecall to display captured items more-or-less exactly as they appear in the Finder. Metadata includes an item's icon, correct localized display name, whether their extension is hidden, and so on. However, if something goes wrong while capturing the display metadata, QRecall does not consider that an error as long as all of the actual file data and important metadata (like extended attributes and ACLs) was captured successfully. The item can be completely restored, it just might not display nicely in the QRecall browser.

The other thing that happens with some regularity is that files disappear. A file may exist in a folder when QRecall begins capturing that folder, but could be deleted or renamed by another process before QRecall actually gets to the point of capturing that file. This is unavoidable in a multi-tasking system with hundreds of processes that are creating the destroying files every second. When this does occurs, QRecall makes a note of it in the log and continues on. This is, most likely, the message you encountered.

Damian,

This message doesn't refer to keeping your computer from automatically going to sleep during an action; that should never happen.

It's the scheduler saying that it doesn't have sufficient privileges to tell the system when to wake or power up before a scheduled action, or go to sleep or shutdown following an action.

It should only log this warning if (a) QRecall has not been authorized to run with administrative privileges and (b) an action's schedule has been set to wake up or shutdown the system when it runs. In this situation, the scheduler can't perform the requested power event.

If QRecall is preauthorized and you're still getting this message, please sent a diagnostic report and I'll look into it. Please note that I'm attending the Autodesk conference this week and won't be able to revew this until I return.

Would it be possible to simply hold off from using that archive for a few days?

I should have another beta ready soon, and it would include the fix I just mentioned which would correctly log the root cause of the problem. That would be much more informative.

Gary,

Thanks for the feedback and the diagnostic report. From the log you uploaded, I can sort of tell what happened, but I can't tell you what went wrong.

When the archive was closing, QRecall wanted to write a new file to the package. Attempting to create and open this file failed. I don't know exactly how it failed, because the next thing that happened is QRecall tried to log the error and path to the file that couldn't be created, but that failed because archive package folder suddenly couldn't be found ... which is ridiculous, since you were just capturing to it. Anyway, this second failure threw another error, which is what eventually got logged.

So, I can't offer a good reason why QRecall was unable to create that file, and without the exact error code it's just guesswork. If I had to guess, I'd say the volume was completely full (unlikely) or something random happened with communications that caused the volume to be temporarily unavailable (more likely).

What I did do was modify the logging code so if something like this happens in the future, the code that logs what went wrong won't, itself, become the source of the problem.

Andy,

Thank you for providing a centralized resource for comparing backup solutions or Mac OS X. I received your e-mail regarding this earlier, but just haven't found the time to respond. For that, I apologize.

I'll be happy to register QRecall at backuposx.co, and promise to get to it within the next few days.

Thank you Gary, and everyone else who sent a diagnostic report about this and similar issues.

I think I found the problem. It was a bug in QRecall that worked in Leopard and Snow Leopard because of another bug in Mac OS X. Apple fixed the bug in Lion, which exposed the bug in QRecall.

Anyway, if I did everything correctly the fix should solve the problem of actions not appearing in the activity window and volume mount/unmount events not triggering actions. The fix will appear in the next beta release of QRecall (hopefully sometime later this week).

Gary K. Griffey wrote:James,
So...I am not exactly sure what is going on here...

That makes two of us.

is a restart required after creating a new scheduled task based on an event?

No, it shouldn't require a restart.

I suspect that it might be related to the inter-process communications problems that's occurring with the activity window in Lion. It's actually the activity monitor process that detects when a volume has been mounted. It then alerts the scheduler of that via a message. If the scheduler isn't getting the message for some reason, that would explain this problem. But that's not obvious from the log.

Please send another diagnostic report so I can compare the sequence of events when it worked and when it didn't.

Thanks.

Gary K. Griffey wrote:When I connect the archive volume...it mounts to the mac normally...but the QRecall scheduler does not kick-off the capture as expected.

First, make sure that QRecall knows which archive it's supposed to be tracking. You can do this by simply opening the action, reselecting the archive, and save it again. You can double check that it's got the right archive by running the action manually.

Also make sure you don't have any other schedule conditions that might interfere (such as "Ignore between x and x").

If that doesn't make any difference, send a diagnostic report. The QRecall log records when volumes are mounted and unmounted, and what actions should be run, were run, weren't run, and why.

Ralph,

Please send a diagnostic report anyway. I'm still interested in gathering more information about why the activity window is sometime not monitoring actions.

In fact, if anyone has encountered this issue in the last week, please send a diagnostic report (Help > Send Report...).