Kevin Crawley wrote:What if I were to restore the files from QRecall running on the cablecast machine?

Oh, then the cablecast machine is another Mac? (I was thinking it was some Linux box or something you used for video recording.) Yes, that would work. In fact if it's a Mac, the best thing to do would be to set up QRecall on that machine and capture and recall directly.

Will I need a new identity key for the cablecast machine for that purpose?

Only capture requires an identity key. See Identity Keys.

If you want to set up QRecall on the cablecast machine to capture, you have two choices. You can reused your existing identity key under the terms of the household license and capture to a separate archive. If you want to capture to the same archive, you should get a second identity key so that QRecall keeps the files in the archive separate.

Try resizing the window and moving the separator bar between the layer browser and the item browser.

If that doesn't fix it, try this:

- Choose Archive > Settings... and make note of your settings.
- Close the archive window
- In the Finder, right/control+click on the archive and choose Show Package Contents
- Drag the settings.plist file out of the archive package. E-mail me a copy.
- Reopen the archive in QRecall. See if your scroll bar has returned.
- Choose Archive > Settings... and restore any archive settings that were forgotten.

I'm assuming that you are accessing the files on the cablecast machine via some sort of file sharing.

The problem is probably permissions. When you access files on local drives, the operating system restricts access based on your logged in user ID. You are limited to what files you have access to and what properties you can set. For example, you can't change the ownership of a file that you don't own.

When you pre-authorize QRecall to use administrative privileges, it lets QRecall run as root which gives it carte blanche access to read and write any file or permission set on your local volumes.

For network volumes the same rules generally apply, but the access given is granted by the remote file service not the local operating system. So it doesn't matter if you run QRecall as root or not, what privileges you have on the remote volume are determined by how you logged in to the remote service.

I suspect that you connected to the comcast box using a user that is different than the one that owns to the multimedia files you captured. Given read access to that directory, QRecall will capture the owner and permissions of those files, but since it isn't the owner it can't restore the ownership and permissions back the way they were.

The only solution I can think of will require that you gain access to that volume in such a way so that you have permission to restore the original ownership and permissions of those files. If you can attach to comcast volume using the owner of those files, that might do it. You might also physically extract the hard drive from the device and attach it to your Macintosh as an external drive.

Got home last night, bought a key this morning, and then started a capture by hand

The problem is that the capture seems to be starting from scratch all over again

Yes, the capture is starting over. The reason is because you're using a new identity key.

QRecall now sees your system as a new owner and (from its perspective) is capturing everything for the first time. As it does this, it notices that every one of your files is remarkably similar to the ones captured by that "other" user who had the trial identity key. So the archive isn't growing substantially, but it will create a new layer belonging to your new identity that contains every item on your volume.

When its done, you'll have two owners in your archive. If you want to recall something from before the identity key change you'll need to switch to the old owner in the Owners & Volumes drawer. Eventually you'll probably just want to delete that owner by selecting the volume belonging to the old owner and choosing the Archive > Delete Item command.

I can't think of any reason why QRecall should interfere with Time Machine. The error associated with QRecall's Preferences folder is especially mysterious, since there's nothing special about that directory at all. In fact, unless you edit an action or an archive is moved, the contents of that directory don't change.

Maybe Apple updated Time Machine to stop working if QRecall is installed.

I suspect that something else went wrong. I have no ideal what error 11 is, and suspect you'll never find out as Apple doesn't publish any Time Machine error code specifics. There's a couple of threads on Apple's discussion forum where people have reported failed Time Machine backups with error -43, but they don't appear to have garnered any response from Apple.

The general consensus of these threads seems to be that "Time Machine is great, just make sure you have a second backup strategy."

I can suggest a few ways of doing this.

The manual method, equivalent to pointing Time Machine at a new drive, is to do that same with QRecall.

- Disconnect the old drive, plug in the new one
- Create a new archive (or copy the one from the old drive)
- Open any action that used the old archive and select the new archive
- Save the action

If you rotate backup drives on a regular basis you could automate this to some degree by creating two sets of actions, one that uses archive A and an identical set that uses archive B. In each action, add an Ignore If No Archive condition.

As long as the drive with archive A is plugged in and mounted, the A set of actions will run. As long as the drive with archive B is mounted, the B set of actions will run.

A slight variation on the second approach is to create a set of actions that run when a particular volume is mounted using the Archive Volume Connects event schedule. Again, create two sets of actions for archive A and archive B. Now, whenever you connect the volume that contains archive A, the A set of actions runs immediately. When you connect the volume containing archive B, then B set of actions start.

I have, but just haven't gotten to it. I'm developing some short videos right now to help explain how QRecall works and how it's different from other backup utilities in general. But I'm sure a feature by feature comparison would be helpful too.

I'm still surprised at the number of people who think they're protected with a clone backup, That is, until they need to recover a deleted or damaged file *after* they've already synced to the clone...

It's truly shocking.

Bruce Giles wrote:There's one thing about QRecall's user interface that bugs me a little. When I'm in the Finder, in a list view window, and I double-click on a folder, the folder opens. When I do the same thing in a QRecall archive window, because old habits die hard, it immediately does a recall of the double-clicked folder.

You are not the first to complain about this particular "feature." I plan to address this issue in the next release.

Usually, that isn't what I wanted to happen. What I wanted was to see what was inside the folder. I wish QRecall had a preference that would let me decide what it should do when I double-click something in the archive. At a minimum, it would be good if it could act as if I had clicked the disclosure triangle.

That's a good suggestion. I've also considered disabling the double-click action so you would be forced to use the Action > Recall and Open command explicitly.

When I do accidentally recall a folder that way, I see that QRecall puts it in a subfolder of /private/tmp. If I remember correctly, that folder is automatically cleared on startup (or maybe shutdown?).

/private/tmp gets cleared on restart and is also (normally) scanned once a day for items that have not been accessed in the last 3 days. (see /etc/defaults/periodic.conf and /etc/periodic/daily/110.clean-tmps).

Does that mean I don't need to worry about explicitly deleting accidental recalls, as long as I don't mind them hanging around until I reboot?

Yes, which is exactly why they get recalled to /tmp.

Thanks for the confirmation, Bruce.

I'll be out of town next week. When I return, it looks like rc2 will become QRecall 1.1.

Thanks again to all my beta testers for your help and feedback. I couldn't have done this without you.

This fix, along with a few other minor changes, have been rolled into release candidate 2. Launch QRecall (or choose QRecall > Check for updates...) to get the new version.

Bruce Giles wrote:I hadn't been changing the default compression level for quite some time, but I decided to try a new backup from scratch with the rc, and for some reason, I decided to change the compression level before I started.

Well, it's a good thing you did or it might have taken a lot longer to figure this one out.

Version 1.1.0b36 should fix this problem. To install and test b36:

- Download the 1.1.0b36 disk image. Open the disk image to mount it.
- Open your Applications folder and locate the old QRecall.
- Drag the old QRecall application to the Trash. Do not attempt to empty the Trash.
- Drag the new QRecall application into your Applications folder.
- Open the new QRecall application in your Applications folder.
- You can now empty your Trash.

Bruce Giles wrote:I hate to throw a show-stopper at you now, ...

It's better than releasing a product with bugs.

If an archive's settings are set to the "slower, smaller" side (all three of the settings), then whenever I try to delete an item from the archive, it fails and I get a message that the archive is damaged.

Bruce, you are a genius!

The release was already held up because I have one user who's archive occasionally gets damaged during a merge. So far the problem would only occur about once every three weeks and I had yet to reproduce the problem here. QRecall reports the same failure as the one in your logs. If the problem is related to compression, I should be able to reproduce and fix both.

If you ever want to quit that high-paying government job and work as a full time QRecall tester, just let me know.

Rob Wyatt wrote:I chose to split it into two capture actions so that I could backup my home folder every hour, but only backup the system when I felt like it (ie: after installing new software, at the end of the day, etc). I figured this might be faster than trying to capture my entire hard drive every hour. Maybe not?

You're correct in that a recapture of your home folder will be faster than trying to recapture the entire volume every hour.

This is exactly what I have set up on my main development system: Capture entire volume once a day, capture my home folder once an hour.

The problem is that when you capture the entire volume you excluded your home folder. Instead of creating a new layer that just picks up any changes made on the volume, you create a new layer that acts as if you deleted your entire home folder before capturing the volume. I',m sure that's not what you wanted.

Rob Wyatt wrote:Since I'm backing up to a NAS, when I log out, the capture action doesn't run. Is there any way to keep the volume mounted after logout?

For networked volumes, I don't know of any way of keeping them mounted after logging out.

QRecall will attempt to remount local volumes when logged out, allowing the action to run. Mounting network volumes, however, depends on system services (like the key chain) that are only available when you are logged in. This is mentioned the notes in QRecall Help > Automation > Scheduling Actions.

Or should I switch from AFP mounts to NFS? Wouldn't auto-mounted NFS shares stay mounted even when the user logs out?

I don't know. It's worth a try.

Rob Wyatt wrote:I currently have two actions set up. One captures my home folder every hour to my Thecus N4100 Pro NAS.

The second action captures my entire hard drive, minus the home folder (when I log out).

Rob, in our discussion of features I forgot to mention that this is probably not a good idea.

I'm sure you are skipping your home folder by excluding it in the filters second of the capture action. When you exclude an item, QRecall treats that item as if it did not exist. What you end up with is a layer containing your entire volume, without a home folder. If you were to restore that layer it would not contain your home folder.

In the action that captures your entire hard drive, it's best to include your home folder. Besides the reason just mentioned, that's the best time to capture your home folder because it's very stable while you're logged out.

There's little or no extra work involved (especially if you're using OS 10.5). Only changes made since you last captured your home folder will be captured.