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.

Thanks for the log file, that's very helpful.

Your log file is very similar to one that I was sent a couple of days ago from another user. It appears that the action executes but never starts working; until you eventually cancel it which wakes it up.

I'll look into this further and will post here when I have an update.

Andrew Daws wrote: The first time it backed up fine, then after that it stuck on opening archive, and when I clicked cancel (which at least it did recognise this time) it said it had found nothing to back up.

That's exactly what it would say if you canceled the capture before it had captured anything.

Maybe it's a Leopard issue, maybe it's not yet ready for public consumption, but I'm very disappointed that this software doesn't live up to its considerable promise.

As I've said, I'd love to see log files. I can only correct the problems I can diagnose.

Fred Stratton wrote:I have been offered the opportunity to repair a network-mounted archive on a number of occasions in the last 2 months. I am still exploring the reasons for this.

I'm always interested in looking at log files if you're having problems.

All the drop-downs and modal dialogs have <integrity> as in <data integrity> misspelt as integrety.

Thanks. I'm editing the menus and help this week, so I'll be sure to fix that one.

Andrew Daws wrote:I suggest that I bin the current log files, and concentrate on my problems with a NAS. And if a NAS does work locally, would I be able to make that available to my clients?

And would it still suffer from this problem of uploading and downloading the entire file?

NAS fall into two types — remote access hard disk (single user) or a hard disk and file server in a box (multi-user) — neither of which will have any of the issues associated with a WebDAV based service.

Let me follow up that rather pessimistic post with something a little more upbeat.

I have been considering a number of changes to the way QRecall stores and organizes files that could mitigate some of the issues with SSS. Some of these changes are being considered for new redundancy and data journaling features currently under development.

But I've also been toying with some king of "archive archive" feature that would split an archive into pieces suitable for writing to a series of DVDs, or maybe an on-line storage system like Amazon's SSS.

It wouldn't be the same as using the archive remotely. But having a built-in method of exporting an archive to off-line storage and then recovering it again might go a long ways towards making services like SSS more attractive for archive redundancy.

After a couple of days of experimentation and research, my opinion is that Amazon's Simple Storage Service (SSS) and QRecall are profoundly mismatched.

Amazon's SSS is based on WebDAV. WebDAV is a web server based file transfer protocol originally designed to update web sites remotely. Amazon SSS, and I suppose any similar WebDAV based system, has tried to use WebDAV to emulate a remote file system.

The fundamental problem is that WebDAV can only transfer files. When you open a remote file, some intermediate agent (JungleDisk, in this case) copies the entire file from Amazon's servers to your local hard drive. When you write and close the file, the entire file is uploaded back to the server. For small files this is great. For large file, the overhead becomes ridiculous, particularly for small changes.

And that's exactly how QRecall works: It makes small changes to very, very, large files.

As an experiment, I created an Amazon SSS account and installed JungleDisk. I created a new archive and captured my Movies folder. This just happened to have about 2.3GB of data in it - perfect for checking for 2GB file size problems on SSS.

The capture completed in less than a minute, since all of the data was initially written locally. When QRecall closed the new archive file, JungleDisk began uploading the repository.data file to the server. My outgoing data is capped at 600Kbps, so 2.3GB takes about 9 hours to transmit.

After 8 hours I checked on it again. There was a "Background Operation Retry" message in the errors and warning pane. JungleDisk was in the process of re-uploading the entire 2.3GB data file a second time. This repeated at least two more times. 38 hours later, JungleDisk finally finished uploading the data to the server. This is not particularly surprising, as the chances of getting a data transmission error in a single file increase exponentially with the size of the file.

I made a small change to a single file and recaptured the Movies folder. When QRecall opened the archive, JungleDisk downloaded the entire 2.3GB archive. This took about a half hour. The capture then ran (about 15 seconds), and QRecall closed the archive. JungleDisk then began uploading the entire 2.3GB archive back to Amazon.

So adding 1.5MB of new data to the archive (a change of less than 0.06%) resulted in 4.6GB of data transfer and took over 9 hours. Not only is this outrageously inefficient, but it's expensive too. Amazon charges between $0.10 and $0.18 per GB transferred. If you updated the archive every day, it would cost approximately 50 times the $0.15/GB monthly storage fee. For this example, the 2.3GB archive would cost only $0.35 to store, but would be hit with $17.50 of data transfer fees.

Some searching on the JungleDisk support forums confirmed these observations. JungleDisk only transfer whole files. It cannot update only a portion of a file, and it cannot retransmit just the portion of a file that has failed to transfer (although the latter is feature they want to add). This makes large file transfers both brittle and time consuming. Amazon and/or JungleDisk currently have a hard 5GB file size limit. In QRecall terms, 5GB is a small archive and certainly smaller than the backup storage requirements of most users.

My conclusion is that there is a serious impedance mismatch between QRecall and Amazon SSS - and probably any WebDAV based remote file system emulator. I suppose this includes .Mac, but I'll have to experiment.

QRecall is terribly efficient at minimizing the storage required to keep multiple incremental captures. Amazon SSS could complement QRecall by using it to mirror a local archive (i.e. uploading the archive once a week or month as an off-site backup). But even in that scenario, the 5GB file size limit would quickly become an issue.