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.

Bruce Giles wrote:Is this a bug, or just something to do with getting into the final candidates?

It was a bug, related to removing the code that supports the beta keys. It's already fixed in the next release.

If the capture action runs, then you have valid key.

Charles Robinson wrote:I can verify, reindex, and repair, just not restore.

If you can verify the archive, then you should be able to recall files from it.

The Restore command replaces the original item with the version in the archive. The key word here is "original." QRecall records the volume information and location of each item captured. It will only allow an item to be restored if the volume matches what's in the archive. If you've reformatted or repartitioned your drives, the volume information (name, creation date, size, identifier, etc.) probably doesn't match and QRecall naturally assumes that this isn't the volume that originally contained the items.

Just recall the items and select the location to recall them to. This can be the same (relative) location on your new volume. The existing items will be overwritten with the recalled ones, accomplishing your "Restore."

If you want to restore an entire volume to a different volume, open the Owners & Volumes drawer, and select the volume. Holding down the Option key will turn the Archive > Restore... command into Restore To.... Choose that command and QRecall will present a list of volumes. Choose the one you want to overwrite, and the entire volume will be replaced with the contents of the captured volume.

Gib,

Could you still send me your log file(s) for the period you were having problems? I'm interested to know if this is just a Tiger issue or whether it happens in Leopard, and if it's similar to the problems that a few other users have encountered.

You can post the log files here, or just e-mail them to james@qrecall.com.

Gib Henry wrote:This screen dump of a log snippet (need log export capability!)

(log files are already flat text files, located at ~/Library/Logs/QRecall -- in the future, just upload or e-mail the .log file)

... shows everything working fine until I installed a newer version on 1/24, then a bunch of different errors, largely helper incompatible errors. If installation requires a reboot, the installer should say so.

The installation/upgrade is not supposed to require a restart, but QRecall is still plauged by a bug in Apple's launchd service that occationally refuses to stop running the old version of the scheduler service even after a newer version has been installed. Steven Alper just posted a similar error caused by the same problem.

I'll report back whether a reboot resolves the issue.

I suspect that the reboot will solve your issue, but please let me know either way.

Steven M. Alper wrote:Installed RC1 and ran. It failed to quit the old Scheduler for the new. I force quit the old and relaunched. It appears (to me) that all is well.

Thanks, Steven.

This is caused by a bug in Apple's launchd. The problem is that the OS restarts the old scheduler even after the new one has been installed. I still don't know why or how to convince it to stop running the old scheduler.

As you've discovered, manually killing the old scheduler or just restarting fixes the problem. Hopefully by the time I get to next dot release I'll have a more elegant solution.

By the way, I did find a workaround that will fix this problem for Leopard users. The fix will appear in the next release.