Thinking about the problem a little more, it could have been a race condition between the Launch Services database (which is responsible for keeping track of what icon each application should display) and the Dock starting up.

Launch Services may have some cleaning up to do following a restore. There are all kinds of subtle differences between a system that is captured while it's running and one that has shutdown. If Launch Services was rescanning some applications, it might not have known what the icon for a particular application was immediately after booting. But eventually it would have rescanned everything and been back up to date when you reset the Dock icons.

I'll chalk it up to a fairly harmless mystery.

Works for me.

I have no idea what happened. But if I had to hazard a guess, I'd say that QRecall captured the Dock's preferences while the file was open and only partially updated. If so, then the restored preferences file was partially corrupt/incomplete. I suspect the Dock preferences and not the Launch Services database, since the application and the replaced dock item have the correct icon.

Ralph Strauch wrote:The Energy saver control pane contains an option to "Wake up for Ethernet administrator access." Would it be possible for qrecall to generate such a request, so that other computers on a network could wake up the one with the backup drive attached to do backups?

I've been putting this off until the network version of QRecall, where it would make much more sense.

In the mean time, try a program like WakeOnLan.

Related question: Could qrecall have an action to wake up for a scheduled backup rather than scheduling the wakup separately in another place?

This is the third request I've received for this feature, but I'm very reluctant to implement it. Macs have a single programable wake up timer. To change it would mean overwriting whatever wake up time you currently have chosen. Then what happens if you create two actions that run at different times that both want to wake up the system? Then what happens if you go back into the system preferences and select a new wake up time? Basically, I'm not a fan of applications that start changing system-wide preferences.

Ralph Strauch wrote:I grant that this can be seen as a case of operator error that shouldn't happen, but inetwork interruptions of one kind or another are not so rare events that they should be discounted. Is it possible to make Qrecall more forgiving of network failures so they don't result in corrupted archives?

Yes it is, and it's the feature that I'm working on right now. If all goes well, it should appear in a beta within the next few weeks.

Andre wrote:How can I set "QRRunningMakesSystemActive" to false?

<http://forums.qrecall.com/posts/list/66.page>

David Stevens wrote:Yes?

Yes.

In general, you should be able to store the QRecall archive on any writable volume: Internal/external drive, USB drive, Flash memory drive, network storage device, networked volume, etc. Time Capsule should appear as a network volume; just create the archive there.

David Stevens wrote:Another way to do it would be to have a particular action "turn on" only when the programme that creates the files is active and/or "in front", as you're only going to want to back up changes when you're working on something. Would that be an easier way to do this

Actually, capturing items while the application is active is the most problematic time to do so. Documents are often "in flux" or only partially written and capturing them at that point in time results in an invalid or incomplete copy of the actual document data.

Applications that write out the entire document at once (like most word processors and graphics applications) are safe to capture once written and would be best served by monitoring a folder for new items.

David Stevens wrote:I'd still like t know what you think about monitoring specific groups of files for saved changes as a capture criteria.

I think it's a great idea. It's been on the future features list for a while now.

Ralph Strauch wrote:I have one remaining problem I wonder if you can offer any advice about. I've deleted the empty qrecall archive from the idisk, but it still shows only 2.4gb of free space rather than the 5.8gb I had before the backup. Apparently it allocated 3.4gb of space for the qrecall archive even though it didn't use it, still keeps that space as used, even though it doesn't show up as allocated to any particular folder. Do you know anything I can do to get that space back?

According to this technical support article all you should have to do is wait 24 hours:

If you recently had an unsuccessful upload to your iDisk,
wait 24 hours, then check the storage space again.
Sometimes an unsuccessful upload can result in iDisk
usage to be reported incorrectly, and waiting 24 hours
allows for any invisible files potentially generated by the
unsuccessful upload to be detected and removed.

After another day if the free space doesn't appear, I'd contact the .Mac technical support. But it should take care of itself.

Charles,

An e-mail notification is a good suggestion. I also plan to make errors more prominent in the monitor window, possibly forcing the window to the front when a warning or error is detected. At the very least, reopening the monitor window when an error occurs which should make it harder to miss.

I like to think of the verify action as a "peace of mind" feature. QRecall constantly checks the integrity of the archive whatever it is doing (capture, merge, recall, etc.) and will stop immediately if it finds anything amiss.

So at first blush the verify appears superfluous. But no action touches everything in an archive. The verify is the only action that ensures that everything in the archive is valid, readable, and has not been altered or corrupted in any way. I tend to schedule verifies to run at least once a week, even once a day on small archives.

Tip: If your archive is on another computer, create the verify action to run on the server. It will run much faster than it would over a network connection. The same is true for merge and compact actions.

Ralph Strauch wrote:Here's log for my previous posting. I attached it to that posting and it showed up as attached, but the post itself showed up with <br>'s in place of the returns, I guess because I wrote it in a text processor and pasted it in.

No, this is a bug in the JForum software that runs this forum. It can usually be avoided unchecking the "Disable HTML in the message" option. I don't know why.

Hopefully this will get fixed when we upgrade to the next version of JForum.

Ralph,

I'm profoundly sorry to be the bearer of bad news (again), but using QRecall with Apple's iDisk service does not work well.

There was a long thread on this some time back (Online Storage). To avoid the pain of reading the whole thing, I'll summarize:

Apple's iDisk, Amazon's Simple Storage System, and similar services are all based on the WebDAV protocol. This is file transfer protocol originally designed to make it easier to maintain web sites. Over time, it's been co-opted into a general purpose remote file storage service.

The problem is that WebDAV is not a remote file protocol and it cannot make small modifications in a large file remotely — which is exactly what QRecall does all the time. To simulate the ability to arbitrarily modify files, the OS silently downloads the entire remote file (the QRecall archive in this case) onto your local drive, allows you to update it locally, then copies the modified file back up to the server when the file is closed. For really small file, this is fine. But for making small changes to large files it is horrifically inefficient.

What you observed was QRecall capturing all of the documents to the local copy of the archive. Since this was a local copy, it also happens very quickly making you think "wow, this is really fast!" When the capture was complete, the archive file was closed and the actual work of copying the data to the iDisk began. What you perceived as QRecall "hanging" was actually the WebDAV service copying the finished archive to the iDisk server. This is consistent with the observed behavior and the I/O errors in your log file.

For small incremental backups of important documents, I highly recommend a small USB thumb drive or just create a small archive on the same disk. For an off-sight backup, occasionally copy the archive to your iDisk.

The "waiting for archive" occurs when QRecall believes that some other process has the archive document open for reading or writing. Could you describe the arrangement (whether the archive is on an external drive or a network volume, etc.). It would also be extremely helpful if you sent me your log file (~/Library/Logs/QRecall/QRecall.log).

The type of identity key shouldn't make any difference in this case.

I'm curious to why the problem occurred, but I suspect that a restart will solve it.

Ralph,

Thanks for sending me your log files.

It hard to tell what's going on, but whatever is happening appears to be related to your external hard drive unmounting in the middle of a QRecall action.

For example, the log you sent shows the Repair starting at 2008-03-13 01:48:19. Three minutes later (01:51:48), the volume "spare" (the one containing the archive) was unmounted. The operating system will not normally allow a volume to be unmounted as long as there are file open on that volume. I can only conclude that the hard drive or its interface was physically disconnected or powered down. This will most certainly cause any capture or repair action to fail and leave the archive in an incomplete state.

You also mentioned that you forced the action to quit, but had to restart your computer anyway. Make sure you are stopping or quitting the QRecallHelper process. Quitting the QRecall application (from the Dock or any other way) will have no effect on any archive commands or actions that are running. Each archive operation runs in a separate process (this is how actions run in the background, or even when you are logged out) and will continue to run after the QRecall application quits. If you can't get an action to stop using the stop button, launch Activity Monitor, locate the QRecallHelper process, and quit that.

From what you've sent me, I still suspect that your external drive is disconnecting spontaneously while QRecall is writing to it and this is the root of your problems.

Ralph Strauch wrote:I'm attaching a file containing the log starting at the point that I mounted the backup drive.

The log file didn't get attached. You can just mail it to james@qrecall.com and I'll take a look at it.

I restarted the backup at 2008-03-13 01:43:51.499 and it failed due to an invalid header length. I started a repair at 2008-03-13 01:48:19.045 and went to bed. When I got up the next morning I found that the repair had failed almost immediately at 2008-03-13 01:48:20.562 due to "Found 24 bytes of invalid data at file position 2424."

That, by itself, will not cause the repair to fail. It's just an informational message telling you what QRecall found wrong with the archive. The repair is specifically designed to discard errors and corrupted data and reconstruct the archive from all of the data that still OK. What you want to look for is either "Repair complete" or "Repair failed".

It also looks "from the log as if the backup disk was dismounted shortly thereafter. It was not mounted when I checked it in the morning.

If the volume unmounted, then that's a good reason why the Repair would fail.

To help you interpret the log, MBPHD is the source drive on my MacBook Pro being backed up. "spare" is the backup volume, and the backup disk also contains volumes "leopard" and "Mac OS X Install DVD." The unmounted backup disk is the same condition I described on March 8. I assumed then that it was a problem with my drive, but now seeing it occur again immediately following a Qrecall failure I wonder if that is the case. Can you tell from the logs? Are some of these problems with my system, or is it all due to QRecall?

My money is still on a problem with that drive or your FireWire interface. QRecall will never cause a drive to dismount. However, a drive that spontaneously dismounts will certain wreak havoc with any application that is writing to it, including QRecall. The error you encountered before was due to a write failure on that drive. Since the same thing happened again, I assume that QRecall encountered another write failure while trying to write to that drive.

In any case, I think QRecall needs a softer failure mode, allow the program to exit properly without requiring a force quit and sometimes even a reboot.

It does. If a call to the operating system fails, QRecall will exit gracefully. However, if a call to the operating system hangs there's nothing QRecall can do about it; it isn't in control of the process anymore. I might be able to tell more when I see the log file.

The log file also includes a lot of entries for time periods when QRecall isn't active. Is this normal?

Yes. First, QRecall is always active. The scheduler and monitor processes run continuously. I've left a lot of debugging messages in the log to help diagnose any potential problems. Diagnostic messages that provide little use over time eventually get turned off.