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.

John,

Thank you very much. That was exactly the information I needed to find and eliminate that bug. It was a rather nasty one, so I'm glad you contacted me about it.

The fix is available immediately in QRecall 1.0.0(55d). To try this version:

1) Download the disk image (using the link above)
2) Trash (or set aside) your current version of QRecall
3) Copy 1.0.0(55d) to QRecall's previous location
4) Launch the new version

This fix will also appear in the next public release. If you encounter similar problems with 55d or later, please let me know immediately.

John,

Thanks for the QRecall log. The scheduler is definitely losing its connection with the action. Unfortunetly, there's nothing else in the log to tell me why. Do you have any crash report files in /Library/Logs/CrashReporter that start with QRecall? If so, select them all, create an archive, and send those to me. If the helper is crashing, this should tell me why.

Hello John,

It sounds very much like the helper application is crashing.

Please forward me your log files (just zip up your ~/Library/Logs/QRecall folder), and any crash reports in /Library/Logs/CrashReporter that start with QRecall.... You can post those here to the forum, or just send them directly to me (james at qrecall.com).

I still don't know what the cause is, but there's a way to work around it.

Hide the QRecall application or minimize the archive window. When you make the window visible again, the mouse tracking will start working again.

Nice catch. I hadn't notice that. It's definitely a Leopard issue, as it still works on Tiger.

All of the hover effects depend on a special kind of "mouse moved" event notification. Clearly something's changed. I'll look into it and post back here.

I've spent considerable time looking into this, but have drawn a blank. It appears that your capture action was simply "stuck" opening the archive. But I can't reproduce it here, and I can't imagine any reason for this to happen.

To help diagnose the problem, I've prepared a test version of QRecall I'd like you (and anyone else who's interested) to download and try. It's identical to the 1.0.0(55) release except that it logs detailed messages to the log file as the repository files are opened and closed. Hopefully, this will give me enough information to figure out what's going on.

Download: QRecall 1.0.0b(55)c

To install

1) Trash (or set aside) QRecall 1.0.0b(55)
2) Copy 1.0.0b(55)c to the previous location of 1.0.0b(55)
3) Launch 1.0.0b(55)c

You will need to reauthorize it. Afterwards, perform a number of captures. If the action still get stuck at "Opening archive", cancel the action and forward a copy of the log file to me. (You're welcome to send me log files even if it doesn't get stuck.)

I've fixed all of the occurrences of this I can find, but those changes haven't migrated to a public build yet. They'll show up in the next release of QRecall.

Very interesting. What's curious is that those messages are from the debug version of the malloc libraries, and as far as I know I didn't ship any versions of QRecall that use the debug malloc library. It might be possible that you have an environment variable set that enables this (this might even be standard on the server). It's worth investigating.

Regardless, the messages appear to be coming from the QRecall client. Since you suspect that this occurred in the last 48 hours, do you happen to remember what you might have been doing in the QRecall application lately? This would help me in trying to reproduce the problem.

Both of these goals should be easily achievable with QRecall.

Martin G. Kaiser wrote:- safeguard my data files up to the last few hours, as well as maintain older versions of files

Create a capture action that captures your Documents folder (or whereever your working data files are) every hour or two.

- being able to the restore older versions of the OS-X. I'll explain: If I run into a nasty OS-related misbehavior and then I remember that 2 weeks ago I did not yet have that issue, then I'd like to restore the OS' state of 2 weeks ago.

Regularly (i.e. daily) capture your entire startup volume.

When you need to recover an earlier system, open your archive and rewind to locate the earlier set of files you want to restore. Choose View > Show Hidden Items and select the system files you want to restore (/System, /private, /usr, mach_kernel, etc). Then choose the Restore command and let QRecall get to work.

Now, while QRecall can easily let your restore any earlier set of files, restoring an earlier version of your OS without erasing your data is a little tricky. For example, the Library folders contain code and frameworks but also history and preferences. You might need to restore older plug-ins, but you probably don't want to restore your old preference files.

And anytime you are upgrading/downgrading your system files it's best to do it while booted from a second system. QRecall can perform "live" captures and restores of your booted volume, but the system can become unstable if you start replacing its resources while its running.