I have set QR on my Macbook Pro (10.6.8) to run on connection of the external drive and every 12 hours thereafter.

A recent back-up stopped with a 'low grade' error message to the effect that QR couldn't back certain files up - apologies for the lack of the precise wording, I didn't screen dump that message and don't have the Macbook with me at the moment. I was in a hurry so I reran the back-up and all completed correctly. When I looked in the log later, the error was flagged with a blue 'i' when I would have expected a red 'x'. And the detail provided when I expanded the log, was small, it certainly didn't identify where the problem had arisen. The impression this gave was that QR didn't consider the failure to be more than a minor event, to me it might have have been serious especially if the second back-up run had failed. Worth considering upgrading the importance of such messages?

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.

Thanks for the reassurance. While I always run back-ups when no programmes that I have launched are running, I appreciate that the system may well be changing files at the same time and without my knowledge.