Currently, the volume containing the archive must be mounted before the action is run. In fact, if you told QRecall that your archive was on a removable or network volume, the assistant will add a condition to the action to skip it if the volume isn't connected when the action runs.

I'm looking into auto-mounting the archive volume when an action runs, possibly making it a an option in the action.

This is (mostly) normal.

There's a bug in the current version of the log viewer that displays some internal/low-level log messages. The extraneous log messages you are seeing are about low-level communications passed between processes.

The next version of QRecall will correct this display problem. You should only see the high-level "Compact Stopped by user" message(s).

Tell me about the error, or (better) send me your log file.

QRecall is very conservative in the criteria is uses to determine when a file or directory might have changed and needs to be recaptured. In this case, all of the files on the volume are new (since they were all rewritten when you restored the volume). It's only logical that QRecall would see them as new files and capture them again.

Since all of the files contained the same data as the previously captured items, no new data was added to the archive ? thus, the 99% duplicate message.

As for the exact mechanics involved, the likely suspect is the attributeModDate property of each file. This property is changed whenever any file metadata is set or changed. Recalling a file sets the metadata of that file to its recalled state, which subsequently changes its attributeModDate. The next time the file is captured, the file's new attributeModDate doesn't match the attributeModDate of the previously captured item, so QRecall recaptures it.

Great minds must think alike. I was contemplating this very feature yesterday (probably for the same reason).

As for an interface, I was thinking of adding an editable "notes" field to the info drawer, akin to the notes of an iCal event.

If I had to guess, I'd say that some of your folder names begin with <space> and others begin with Option+<space> (non-breaking space).

QRecall uses a Unicode comparision function supplied by Mac OS X that's supposed to sort exactly the same way the Finder does. Clearly some investigation is in order. Which is actually good timing, as I'm in the process of reengineering the way that strings are managed internally.

Bruce Giles wrote:Actually, the title of the page is "Recall Items", not "Restore Items". And that was part of my problem. I knew the command I wanted was "Restore To", so when I saw this page, the title caused me to think it was about the Recall command only, and I therefore didn't really look at it.

That's a good point. I might break out the Restore command and give it its own page.

Bruce Giles wrote:Is the "Restore To" command documented in the help? I couldn't find it, but, but maybe I wasn't searching the right way.

QRecall Help > Capture Basics > Restore Items. After the basic restore instructions, there a note on how to restore a volume.

How were you searching? If I search the help for "restore volume" or "recall volume" the Recall Items page is the first hit.

I finally noticed the "Show Owners & Volumes" command in the View menu.

Oh, that's embarrassing. The help really should mention that you must open the owners & volumes drawer in order to select an entire volume.

The latest release resolves this problem.

I purposefully disabled resursive expansion (holding down the Option key while clicking an enclosure triangle) in the browser. The problem is that a single folder could potentially expand to thousands, or even hunderds of thousands, of items. QRecall *might* eventually come back after 10 minutes, if it doesn't simply blow up the operating system's outline framework (which is not designed to display that many items at once).

However, I'll look into revisiting this. I might limit the expansion to two or three levels, or maybe stop expanding subfolders once two or three hundred items are revealed. This might make you repeat the process to display everything, but it would certainly be less work than it is now.

Bruce Giles wrote:Option 1: Using a second Mac, ...

Yes, that would work.

Bruce Giles wrote:Option 2: I reinstall the OS on the original computer. Once it's reinstalled, I reinstall QRecall and then connect the backup drive and do a restore back to the original computer.

That will work too. QRecall can perform a "live restore" of the currently booted operating system (assuming you have a little free disk space). The operating system, naturally, can become confused if you try to use it while it's having its brains operated on.

What you'll want to do is:
1) Reinstall the OS. Don't bother upgrading, you're about to replace everything anyway.
2) Run QRecall, open the backup archive, select the volume to restore, hold down the Option key and choose the Archive > Restore To... command.
3) Do absolutely nothing with the OS or any applications while the restore is in progress.
4) When it's done, immediately restart.

The potential problem I see is that I'm trying to Restore the OS (among other things) on top of an already running OS. I'm guessing there are files that are open and in use that QRecall can't overwrite.

QRecall works around this problem by going to the BSD file APIs. These allow QRecall to overwrite (or delete) a file that currently in use. The original process uses the original file until it is closed. It seems counter-intuitive, but it works.

Is there a better way than either of these two options?

Create a bootable recovery drive.

If you're external drive is the kind you can boot from, install a minimal operating system and a copy of QRecall. If anything happens to your main volume, boot from the external and restore what you need.

1) Use your OS installation CD/DVD to install Mac OS X on the external drive. When you perform the install, customize the installation by unchecking all optional packages: Your recovery OS doesn't need extra fonts, or languages, or printer drivers. When the installation is complete, you can further trim the OS by discarding superfluous applications, like Chess. I typically throw away everything except Disk Utility and Terminal.

2) Copy QRecall to the backup drive

You now have a completely reliable emergency boot drive. Since the OS is stable (is not a copy of your working OS), there's no chance that any mishap or failed upgrade that could make your primary OS unbootable will affect your emergency system. You can boot, reformat, perform diagnostics, and restore with impunity.

Good eyes.

This won't make it into the next release, but should be included in the one after that.

This appears to be a race condition bug. Just out of curiosity, are you running QRecall on a single or multi-processor Mac?

I think I've resolved the problem. If you want to experiment, I've uploaded an inter-release build: http://www.qrecall.com/release/QRecall_1.0.0b42.i.dmg. Warning: This has a bunch of other untested changes, so try it at your own risk.

To install the new version: (1) download the disk image. (2) Trash (but don't delete) your currently installed version of QRecall. (3) Copy the new version into its place. (4) Launch the new version and reauthorize it. (5) Delete the old version.

Bruce Giles wrote:I re-launched QRecall and tried to open the same archive again, and this time it opened without any problems. I did not get any warnings about needing to reindex or repair the archive, so presumably it was unaffected by the crash.

When browsing, QRecall opens the archive in read-only mode. So browsing can't alter or damage the archive in any way, no matter what happens to the application.

(Well, that's not entirely true. You can change the archive settings while browsing, but the worst that would happen is the archive would lose its custom settings.)

Bruce Giles wrote:I now have an archive with a number of layers marked as "Unknown Zero KB -Damaged-", except for the latest layer, which is good. I'm currently merging all the layers, primarily just to see what happens. If I do a verify after that, and it checks out, then it should be safe to continue using, right?

Yes. If the last layer merged is complete, the merged layer will be complete.

Although if I decided to toss this one out and do a fresh capture, it should work this time, since I've apparently fixed all the folders that were vulnerable to the launch services bug.

That's the theory. I'd be very interested to know if you find otherwise.

Bruce Giles wrote:That sounds pretty cool, if it works. But suppose I have a 15 GB iTunes Music Library. I capture it, add album covers to a dozen songs, and then recapture it. Would the experimental code likely catch this and just backup the changed quanta on those 12 (out of 3000 or so) songs?

It would do that now, even if you turned shifted-quanta detection off. Duplicate quanta and shifted quanta detection are different. Duplicate detection works 100% of the time.

Shifted quanta detection is the special case where data is "shifted" relative to its previous location in a file (typically by reading it into memory, then writing it back out at a new location). iTunes and iPhoto don't typically shift any significant amount of data when one changes the metadata of a song or picture. This metadata is either stored separately, or tacked on to the end of the file. Either way, the bulk of the MP3, AAC, or JPEG data isn't changed or moved.

OK, but once the archive has been compressed, is there still a performance hit?

Yes, big time; which is why I don't recommend its casual use.

Once data in an archive is compressed, every operation that needs that data again requires QRecall to decompress it. During a capture, everything about a file has to be decompressed before it can be compared to the existing file. This is probably the biggest performance penalty. Browsing a compressed archive also requires decompression of every chunk of compressed file information. The same is true for merge and verify actions.