It would be really useful if there was some way to sort all files in an archive by size, and then selectively delete them.

At various times, I've had lots of large files on my system that existed long enough to get backed up, but for which I don't really want to keep any backups. For example, movies and TV shows, obsolete virtual machine files, etc.

If I knew where they were on my hard drive, and when, I could find them in the archives and manually delete them. But if I don't remember that, finding them can be difficult. If there isn't an easy way to do this, then consider it a feature request.

First of all, congratulations on the release of version 1.1!

Today, I upgraded our XServe running Tiger Server to QRecall 1.1. Everything seems to have worked perfectly.

I was having no problems under 1.0.1, but I ran a verify before upgrading, just to be sure. After the upgrade, I verified the archive again, and there were no problems. Following that, I re-indexed the archive to take advantage of the Spotlight search capability that was mentioned in the upgrade notes. Finally, I ran a full recapture of the hard drive.

The recapture went very quickly, though I didn't actually time it. After it completed, the archive window reported that the size of the captured layer was about the same as typical recapture runs under 1.0.1. But the number of items captured was over 7000, where it's typically no more than around 300. Is this because it picked up (captured) extended attributes that weren't captured in 1.0.1? Does my upgraded archive now contain everything that it would have had if I had started a new archive instead of upgrading the old one?

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

That's pretty much what I thought. And no, I was not editing an action at the time. The QRecall app wasn't even running.

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

I'm beginning to think so...

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.

Yeah, I did some searches on that myself and didn't turn up anything useful.

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

I have to agree. I've had several cases where Time Machine has claimed various mysterious errors and sometimes I've had to delete the Time Machine backup files and start from scratch to get it running again. I have not had any problems like that with QRecall

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

This is exactly what I do, and it works quite well. I generally swap the two drives every Friday, but if I forget, the actions continue to run on schedule, backing up to whichever backup drive happens to be mounted.

Compare that to Retrospect, where, if the expected drive isn't there, the backup script halts and does nothing until you connect the drive it wants.

Steven Arnold wrote:Incidentally, I backup my files using QRecall to an encrypted disk image all the time. Works great. THis is in sharp contrast to Time Machine, which does not support backing up to disk images at all, to my knowledge.

It might also work (with either Time Machine or QRecall) to back up to an encrypted drive. TrueCrypt is a free, open source program that can encrypt entire drives or partitions.

http://www.truecrypt.org/

If anyone tries it, let us know if it works.

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

That would work for me. I never remember that double-clicking an item will do a recall anyway, until I do it unintentionally.

Have you thought about adding a page to your website that compares the various Mac backup programs, like Retrospect, Carbon Copy Cloner, SuperDuper, QRecall, etc? Maybe something like a table, with a feature list down the side, the different products across the top, and cells filled with green check marks or red "x"s. It might be a good opportunity to educate prospective customers, especially if they're already using one of the programs and they think it's doing everything they need.

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...

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.

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 not quite the same as what happens in the Finder, but it achieves a similar result.

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?). 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?

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

I've tried the latest rc on two different Macs now. So far, I haven't run into any problems at all on either of them.

James Bucanek wrote:

Bruce Giles wrote:If I added a "ignore if no archive" condition to each of the actions, would that help?

That will fix the problem. Conditions are evaluated when the action is started, so as soon as the action is started it will check its conditions and skip the action (assuming the volume isn't online).

OK, I've added that condition, and we'll see how that does. Thanks!

-- Bruce

James Bucanek wrote:At 16:07 you logged out and shutdown. During the shutdown, the scheduler made a note of all the actions that were currently scheduled to run.

Yeah, I probably did exit before everything finished on that day.

The perfect storm of events that led up to this were:

- A bunch of actions that were automatically scheduled to run at some distant time in the future.
- A scheduler that was shutdown before the "Backup Disk" volume was unmounted (the scheduler never saw the volume go off-line which would have canceled the repeat schedule)

Sometimes when I shut down, I unmount the external drive first. Sometimes I don't. I can't recall which way I did it last week. My guess is that I shut down without unmounting first, and during shutdown, OS X probably kills running tasks (like QRecall) before it unmounts drives.

I'm not saying that it should work this way, but that's what happened. What probably should happen is that the scheduler should assess the state of the mounted volumes first before starting any previously scheduled actions. But there are coding challenges that could make that difficult.

Thanks for the explanation -- that mostly makes sense. But one thing still confuses me -- the part about the scheduler assessing the state of mounted volumes. When I started up this morning, the external drive WASN'T mounted. It wasn't even plugged in yet.

If I added a "ignore if no archive" condition to each of the actions, would that help?

-- Bruce

James,

I think I have some invisible "orphaned" actions, probably as a result of testing various versions of QRecall. All the actions currently defined in my Actions window are configured to run "after volume connects". But when I booted my MacBook Pro for the first time in a week this morning, as soon as I logged in, before I had connected the external backup drive, the QRecall monitor window popped up and told me it was trying to capture. The capture, and, I think, a subsequent compress, didn't run and the error message was something like "archive file not found". (I probably have used several different archive names in my testing.) Sorry I don't have more details, but I was in a hurry to get something else done this morning, so I just dismissed the messages and decided to deal with it later. This is later.

When I did plug the external drive in, then the actions that I expected to run did run and there were no problems with that.

Where would the invisible actions (if that's what they are) be hiding, and how can I get rid of them? I'll send you a report from the latest beta as soon as I send this, so you'll have the log files.

-- Bruce

James Bucanek wrote:That's fascinating. If you asked me yesterday if I thought this was possible, I would have said no.

Leave it to me to discover something no one thought possible...

That would be my guess too. It would be interesting to see if the UUIDs of the volumes are the same. You can see the UUID of the volume using the 'diskutil info <device>' command from the terminal. If the volumes do have the same UUID, then for all intent and purposes the system will assume that these are the same volume.

I was back in the office today, so I checked both drives. The UUIDs are different. In fact, they're not even close to being similar. I only had one drive connected at a time, and I noticed they both showed a device node of /dev/disk0s2, but maybe that's normal. Frankly, I'm a little afraid to connect both drives simultaneously.

Anyway, everything still continues to work.

-- Bruce

I discovered something today which seems to be quite useful, although I suspect it's a bug. (Whether the bug is with QRecall or Mac OS X, I'm not sure.)

This occurred with our Xserve, running OS X Server 10.4.11 and QRecall 1.0.1, though I suspect the non-Server versions of Tiger and Leopard will probably do the same thing.

Apologies in advance for the tediousness of this report, but it's necessary to accurately describe what I did.

I was setting up two new external backup drives for the server. I formatted the first drive, then installed a minimal copy of Tiger Server on the drive -- just enough to boot and be able to run utilities. I also put a copy of QRecall on the drive and made sure to set it up with the identity key. I rebooted from the external drive to be sure it worked, which it did. I rebooted again from the internal drive.

Now I had a working external drive, called "Xserve Backup A". Next I connected the second external backup drive, so that both were connected simultaneously. Next I ran Disk Utility and duplicated "Xserve Backup A" by using the Restore function of Disk Utility. This left me with two drives both called "Xserve Backup A", so I renamed one of them to "Xserve Backup B". I then unmounted "Xserve Backup B".

Now, with only "Xserve Backup A" mounted, I used the capture assistant to create an archive, also called "Xserve Backup A" and stored on the external drive, and a set of actions for it.

Next I unmounted "Xserve Backup A" and mounted "Xserve Backup B". I created a new archive called "Xserve Backup B", and stored in in the same location on the "Xserve Backup B" drive as the "Xserve Backup A" archive was stored on the "Xserve Backup A" drive.

Much to my surprise, I discovered that the actions I had created for "Xserve Backup A" were now pointing to "Xserve Backup B". I did more testing and confirmed that whichever external drive is mounted, that's the drive the scripts work with. In fact, when "Xserve Backup A" is mounted and I open the Actions window, all the actions list "Xserve Backup A" in the Archive column. If I then unmount the "Xserve Backup A" and mount "Xserve Backup B", and then open the Actions window again, I'll see that all the scripts are now pointing to "Xserve Backup B".

So, I can have a two-disk rotating backup set with only one set of scripts.

Why does it happen? I'm guessing that when I duplicated the drive in Disk Utility, it probably duplicated some hidden volume ID number as well, which wasn't changed when I renamed one of the drives. And QRecall probably uses that volume ID number instead of the volume name to connect a script with a particular archive.

So, is there a downside to doing this? It seems to be working so far...

-- Bruce

James Bucanek wrote:

Bruce Giles wrote:I can send you the log if you're interested.

Yes, thank you. Try the new Help > Send Report... command.

Done!