A few users have written about (apparent) anomalies when using QRecall with Leopard's Spaces feature. This affects the appearance and placement of the QRecall Activity window.

The problem is that QRecall Activity window belongs to a hidden application named QRecallMonitor. As such, the QRecall Activity window will appear in whatever space was active when the monitor started (typically when you log in). Opening the activity window from the QRecall application or by starting an action may switch spaces. This can be disconcerting, to say the least.

To fix this:
• Open the Spaces panel in the System Preferences
• Click the plus button to to add a new application assignment
• In the open dialog, press Command+Shift+G to get the "Go to" panel
• Type, or paste in, the path "/Applications/QRecall.app/Contents/Resources" (without the quotes). If your QRecall application is someplace other than the /Applications folder, change that portion of the path as necessary.
• Click the Go button
• In the Resources folder, scroll down and select the QRecallMonitor application
• Click the Add button
• Find QRecallMonitor in the Application Assignments list and change its Space assignment to "Every Space"
• Log out and log back in

The QRecall Activity window will now appear consistently in all spaces.

QRecall has been extensively tested on Mac OS X 10.4 (Tiger), both client and server, as well as Mac OS X 10.5 (Leopard) client.

I know of a handful of users running QRecall on Mac OS X 10.5 Server, so I can't say it's been heavy tested there, but there haven't been any reported problems either.

QRecall doesn't directly support write-once media like DVD or tape. How QRecall manages rolling incremental backups is fundamentally incompatible with this type of media.

If your archive fits on a DVD, or you have software what will span data across multiple DVDs (such as Toast Titanium), you can simply burn your working archive to DVD(s) once a month and keep that copy off-site.

There have been a few requests to add this capability directly to QRecall, and it's being considered.

sjk wrote:

James Bucanek wrote:"Usable" is a subjective term.

Was there a more objective one for describing what I meant?

I have no idea.

When people say "usable" it's hard to know if they mean it in a technical way ("I can open and view the contents of an archive") or an subjective way ("I can recover all of my damaged files").

You're clearly a savvy enough user to know that if data in an archive has been lost due to media failure, there's simply no way of getting it back. But I can't always assume that. Some people might think that the Repair command should simply fix the damaged drive and recover all of the lost data!

sjk wrote:Has anyone run a thorough Backup Bouncer test for QRecall?

I just wanted to say that I'd be very interested to see how QRecall performs on this test.

I do know of couple of things things that it will fail on, but I'll let that be a surprise.

Bruce Giles wrote:For those of us who have been through multiple alphas and betas, would it be a good idea to start new archives with 1.0? Or are we OK with our older archives, as long as they verify?

If the archive verifies, you're fine.

There's very little in the way of legacy data structures in the archive itself. Even if you've been using QRecall from the very beginning of the beta program.

sjk wrote:What happens if any of that media develops errors; could a usable archive still be reconstructed?

"Usable" is a subjective term. Basically, QRecall's Repair command can reconstruct whatever valid data remains in an archive.

The archive data structures were designed specifically with the goal of being able to recover as much valid data from a damaged archive as possible. There are also numerous integrity checks to ensure that all files recovered by the Repair command are valid.

For example, unlike a regular file system, each directory record in a QRecall archive store its complete path. This allows a directory to be reconstructed and placed in its proper place in the file system hierarchy even when all of the directory information for its parent directories has been lost.

sjk wrote:One thing noticed is file access times (st_atime fields) are modified on files QRecall reads during captures (at least I think that's when it's happening). I don't rely on that information being usefully accurate on OS X as much as on other more traditional Unix systems but it's still something I'd prefer were preserved, though there'd probably be a performance penalty for it.

QRecall doesn't attempt to preserve, capture, or restore the last access time of files. As you surmised, there's a performance hit. It also (oddly) doesn't set, capture, or restore the file's last backup time. Mostly because QRecall doesn't use it and no one else seems to care.

I have these features on the To-Do list. Most likely they would appear as advanced options.

You can fix your problem by deleting the file /Library/LaunchDaemons/QRecallscheduler501.plist and then restarting.

It would also be a good idea to go into your Accounts system preferences pane and check your login items. If you have a login item for QRecallMonitor, delete it too.

Here's what happened:

You kept on using beta version 1.0.0(51), which I think expired sometime during the Reagan administration.

Around version 1.0.0(55), the names and locations of the scheduler's configuration files changed. Versions 1.0.0(55) through release candidate 2 included code that would look for these pre-(55) installations and delete them automatically.

But since you skipped directly from 1.0.0(51) right to the final release (which has no beta version clean-up code), you ended up with both the 1.0.0(51) and the 1.0 schedulers installed simultaneously.

I'm pretty sure I know what the problem is, but I'd like to confirm that first:

Could you list the contents of the following three directories for me?
/Library/LaunchAgents/
/Library/LaunchDaemons/
~/Library/LaunchAgents/

Dawn to Dusk Software is pleased to announce the commercial release of QRecall 1.0.

This also marks the opening of the General discussion forum. General topics that aren't better served by the Cookbook/FAQ, Problems/Bugs, or Suggestions/Feedback forums should be posted here.

This also marks the end of the current beta testing phase. When the next beta version is available, an announcement will be made in the Beta Version forum.

I hope you enjoy using QRecall as much as I've enjoyed developing it.

Thank you for the log files.

When you elect to NOT run actions while logged out, your scheduler is started when you log in. In your case, the application that starts it wasn't properly installed as a login item for your account. So the scheduler didn't start automatically when you logged in.

This has been fixed for the final release.

Nik Jewell wrote:Corrupted file or a QRecall problem?

I've seen this problem before. My money is on a corrupted file.

Does it happen every time? What happens when you try to copy the file someplace else using the Finder?

Also, you might try repairing the volume using Disk Utilities. If this is your startup volume, you'll need to run the Disk Utilities while booted from another partition or your installer DVD. (It's also possible to repair it at startup with a little command-line magic.)

What's happened is your QRecall scheduler wasn't running until you started up the QRecall application again. As soon as you started the QRecall application it realized this and started the scheduler, which took off and started running all of the past-due actions.

Why it wasn't running and how it was installed is dependent on a number of variables: what OS you're running, how your preferences are configured, and so on.

So rather than play twenty questions, the easiest way to diagnose this would be for you to send me your log files. The log files are in your <home folder>/Library/Logs/QRecall folder. Create an archive of the QRecall folder and either e-mail it directly to me or upload it to the forum. These should paint a clearer picture of what's going on.

Whoops! That seems to be mistake in the version resource string, which appears in the about dialog. But as long as the numeric version is 1.0.0.58 then you're running RC2.

RC2 was just a patch before the final release, so this will go away very soon.