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...).

Ralph Strauch wrote:The Activity Monitor shows the backup as waiting for the archive, but then when the archive is mounted the backup starts and then immediately stops, with nothing captured. The log shows a cancel request at the time the archive was mounted. If I then manually trigger the backup, it runs normally.

Well, that's certainly strange. Start by sending a diagnostic report, as there are additional details about who sent the cancel request and why which don't show up in the regular log window.

Also, the activity monitor doesn't accurately reflect what's going on. Right now mine shows that it's waiting for the next scheduled backup, while I'm in the middle of compacting layers. The log correctly show the compaction as in progress.

This is a known problem. In Lion, the activity monitor process sometimes fails to see when an action starts and thus doesn't monitor it. I've narrow this down to a specific notification message that isn't being delivered, but I don't know yet whether this is a bug in Lion or QRecall.

Matthew,

Thanks for the sample output and the diagnostic report.

Your QRecallHelper process is indeed stuck and I vaguely remember this problem.

It would appear that QRecall is encountering an I/O error from the volume containing the archive:

2011-10-26 10:13:23.675 +0100 Details archive I/O error

2011-10-26 10:13:23.675 +0100 Details Cause: <IO> cannot read hash entry { API=FSReadFork, Pos=620910680, OSErr=-36, Length=12, File='/Volumes/My Book 1/Current Work Backup.quanta/hash.index', Class=CarbonFile }

There's a bug in 1.1.4 that when this kind of error happens, an internal dead-lock occurs and the process gets stuck.

So I suspect that you're having random problems reading/writing to your external drive.

First, make sure there's nothing wrong with external drive's volume format. Use Disk Utility to repair the volume.

Then make sure the QRecall archive is in good shape by running a Repair on the archive. I would also highly recommend that you schedule verify, merge, and compact actions to run on a regular basis. At that very least, schedule a verify to run once a week. This will alert you to any possible data integrity problems that might have crept into your archive.

This could, ultimately, be a hardware problem with the external drive. Once you've done these repair steps, we can revisit the problem in more detail should it reoccur.

Matthew,

Without doing some additional research, it's hard to tell what might be going on. From experience, I can tell you that actions can sometimes get stuck when network communications breaks down, but it's not clear that this is the case here.

If you want to diagnose the problem, here's what I'd suggest:

- You didn't mention what version of QRecall you're running. If you have Help > Send Report... command in your QRecall menu, then start by doing that.

- Open the Activity Monitor application, filter on QRecall, and find the QRecallHelper process. This is the process that actually performs whatever action you're running (and is why it doesn't stop when you quit QRecall). Find the process ID number (PID).

- Open a Terminal window. Enter the following command

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

... where PID is the number you found in the previous step.

Enter your account's password and wait for the command to finish. When it has, e-mail the QRecallHelper.sample.txt on your desktop to james@qrecall.com.

Now while you're still in the Activity Monitor, you can kill the QRecallHelper process: select the QRecallHelper process and use the Quit/Force Quit command. This is faster than restarting, and accomplishes the same thing (when you restart, Mac OS X force quits all stuck processes).

Open the QRecall application.

Holding down the Shift and Option keys, choose QRecall > Quit and Uninstall from the menu.

Complete uninstall instructions, including a manual procedure, is in the help. See Help > QRecall Help > Advanced > Uninstall QRecall.

Johannes wrote:... can we get "run Action" with a submenu of all actions as well?

That would be considerably more difficult … but it does sound terribly handy, and I'll look into it.

Johannes wrote:Would it be possible to get a "Suspend all Schedules"/"Resume Schedule" item there?

That would be very easy to add to the menu, just as soon as there is a "Suspend all Schedules"/"Resume Schedule" command.

Seriously, I've had the "Suspend all Schedules" feature on the to-do list for a very long time. I might just take a break from inspector windows and take a swing at it.

Thanks for the feedback.