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

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

Bruce Giles wrote:Why does it happen?

An action document's reference to its archive is stored in a standard Mac OS alias record (the same data structure used when you create an alias file). An alias records volume identification information along with the name, original path, and file identifier of the original object. It then uses these bits of information, in various combinations, in an attempt to locate the original item.

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.

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.

And QRecall probably uses that volume ID number instead of the volume name to connect a script with a particular archive.

QRecall just uses an alias record. The alias does all of the work.

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

Beyond being rather odd, there's little downside from QRecall's perspective. The alias will resolve to one archive or the other. QRecall doesn't care as long as it finds an archive.

I suppose there's some potential for confusion elsewhere. Any alias that refers to recently opened documents, favorites, preferences, and so on could all spontaneously refer to a different document when you mount the other external volume.

If this ever becomes a problem, I suspect that formatting the drive then duplicating it using something like QRecall, ditto, or Carbon Copy Cloner (which just uses ditto) would result in volumes with different identifiers.

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