James Bucanek wrote: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.

This is very cool. If it isn't documented somewhere, it should be, especially for those who don't have the hardware to do a target disk restore.

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.

Also a good idea. I've recently installed an external SATA drive on my G4 desktop, but I'm not sure if it can boot from that or not. I'm guessing not, since I had to install a driver for it, but I'll check into that.

James Bucanek wrote: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.

Interestingly, this seems to be the way the Finder works. If I select a deeply nested folder in list mode and hit command-option-right arrow, it opens them several folders deep, but not all the way. Repeated presses of command-option-right arrow will open successively deeper and deeper folders. I always assumed that was a bug, but perhaps it was intentional.

I've figured out that if I select a folder in an archive, and then hit the right arrow key, it's the same as clicking the disclosure triangle for that folder. Is there (or could there be) a keystroke that not only displays the contents of that folder but all included subfolders, and their included subfolders, etc., until everything contained in the original selcted folder(s) is displayed?

OK, I have my entire hard drive backed up in a QRecall archive on an external drive. Now suppose the internal hard drive crashes, and I have to replace it. So now I've got a Mac with a blank hard drive, and an archive on another drive. How do I restore?

Here's what I'm thinking...

Option 1: Using a second Mac, which I happen to have, I connect the external hard drive, and then connect the first Mac in target disk mode. I think I should then be able to format the new drive in the first Mac right? (Is there any reason why I wouldn't be able to do that?) Once the first Mac has a properly formatted drive, then, while it's still in target disk mode, can I run QRecall on the second Mac and do a Restore to the target disk on the first Mac. Would this work, and then the first Mac is bootable and back to where it was as of the last backup? This would seem to be the easiest and most complete, if it'll work.

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. 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. And if I reinstalled the OS with different options that were used for the original installation, then QRecall may even need to delete files that exist now but didn't exist on the backup. Is that correct? If so, is there a workaround? How does QRecall handle this situation?

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

-- Bruce

James,

Just wanted to report that I tried QRecall on our server the other day, and it did a complete backup of the entire hard drive in one shot, without any problems at all. Didn't even hit the LaunchServices bug. The drive only had about 6 GB of stuff on it however - not much more than the OS itself.

I noticed today that you've got a new version out that works around that problem. I installed it, but haven't had a chance to try it yet. Will do so sometime this weekend.

-- Bruce

This is a minor cosmetic bug, but in the Actions window, for the square buttons in the lower left corner, a couple of the tooltips are backwards.

The one for the plus button says "Edit the selected actions". The one for the pencil button says "Create a new action". I believe they should be reversed.

The plus button does create, and the pencil button does edit, so it's just the tips that are wrong, not the button functions.

-- Bruce

Bruce Giles wrote:I won't try it tonight, since I've got another major capture running, but I may give a shot in the next day or two, if I'm home long enough.

Thinking more about this, I believe I'll wait for the next "official" beta. The problem is that I have been unable to reproduce the crash. I've opened and closed archives a number of times, but QR .42 hasn't crashed on me again. If I can't make it crash "on demand", then I really have no way of knowing if your experimental version fixed the problem.

(Not that I'm complaining. I like it when programs don't crash.

Bruce Giles wrote:I'm doing a new hard drive backup right now. I'll let you know how it goes.

It worked. Did the entire thing in one shot, no crashes.

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

Single processor 933 MHz G4, with 768 MB RAM.

By the way, this computer REALLY slows down after QRecall has been doing its thing for a while. I understand about the pageouts and swapping, but still, 30 seconds (or more) of staring at the spinning rainbow cursor just because I tried to drag an icon from the desktop to the trash??? Once the other apps get swapped back in again, things go back to normal, but until then, it can be agonizing.

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.

I won't try it tonight, since I've got another major capture running, but I may give a shot in the next day or two, if I'm home long enough.

James Bucanek wrote:

Bruce Giles wrote: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.

I'm doing a new hard drive backup right now. I'll let you know how it goes.

When I did the archive of my entire hard drive, I created a new archive, and then immediately created an action to do the capture, because I wanted to take advangate of the filters to avoid backing up caches. So I never actually did a manual capture of the hard drive, I just selected the action and told it to run. So the archive window was never open while the capture was occurring.

As I reported in my previous message, it took me several attempts to get a complete capture. After each failed attempt, I had to open and repair the archive, but I had no crashes during that process. The final attempt appeared to complete successfully, which I deduced because I had no progress window and no error messages showing this time. Since QRecall had no windows open, I clicked on the dock to switch to it, and got the Quick Start window. I chose my hard drive archive from the menu, and there was a brief delay when nothing appeared to happen, and then QRecall crashed. 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. I've attached the crash log. The crash I'm describing here is the last one in the log. (I've just cleared out the CrashReporter folder so any new crashes will start fresh with a new log.)

-- Bruce

(Continuing this from the section where I probably should have posted in the first place.)

James, I finally managed to get QRecall do to a capture of my entire hard drive. It took six or eight attempts, as it kept running into the Launch Services bug you mentioned. I wrote an AppleScript to open and close all subfoldes in a user-selected top-level folder, but that mostly didn't help, as most of the problem areas were inside packages, and the script wouldn't open package folders, so I had to do it manually.

Every time it crashed, I repaired the archive in-place (without copying to a new archive). Then I opened the "questionable" folders on my hard drive until I thought I had taken care of the problem that caused the latest crash, and then did a new capture. 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? 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.

The merge just completed and I now have a single layer that looks to be good. QRecall now reports a size and a date for it, and no longer says "-Damaged-". The verify is running now. I imagine that'll take a while.

-- Bruce

James Bucanek wrote:I current have experimental code that automatically throttles the shifted quanta detection up or down based on past performance and available resources. QRecall will randomly check blocks looking for shifted data. If it finds some, it will increase the amount of time it spends looking for more shifted data. If the data being captured doesn't contain any shifted data, it will throttle the shifted quanta detection back for better capture performance.

If this proves successful, I will replace the shifted quanta archive setting with a simple on/off setting, or possibly eliminate the setting altogether.

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? If not, then I might prefer a manual setting option for those times when I know the changes were "minor".

My advice: Unless you are running out of disk space, leave all compress settings off (faster larger). Compression can dramatically reduce the size of an archive, but it comes at a huge cost in performance. If you have free disk space, use that up before using compression.

OK, but once the archive has been compressed, is there still a performance hit? Suppose I capture something with capture compression turned off and compact compression turned on, and then schedule a compact for later when I'm going to be away at work, so I don't really care long it takes to do the compression. Will the performance of subsequent captures be affected, assuming that capture compression is still turned off?

-- Bruce

James Bucanek wrote:

Bruce Giles wrote:Do I understand correctly that this only happens with folders containing applications?

To be honest, I'm not sure. I've only encountered this problems with applications, but I suspect that it might be related to bundles/packages in general. Again, I haven't been able to get a definitive reason from Apple as to why this is happening so I can't say for sure.

If I get some time later this weekend, I'll give it a shot and let you know what happens.

James Bucanek wrote:If you expand every nested subfolder, then cause the top-level folder to redisplay (by scrolling or collapsing/expanding it), the correct size is displayed.

Ah, so it is. Thanks!

-- Bruce