You know, I was about to purchase SuperDuper but I found it incredibly confusing. I wanted SuperDuper to produce a disk image that could be restored using Apple Software Restore. I did NOT want SuperDuper to make the target drive “identical” to the source drive as I have files resident on the target drive that I do not want altered.

(via Apple’s Discussion Boards—Sorry, Mister Squid, but thanks (really!) for the feedback, more of which can be found in the thread I linked to.)

As I indicated in the thread, users can accomplish this by selecting “Disk Image...” in the destination pop-up in the main window. Anyone else confused, or have suggestions on how we might make this less confusing?

I restored my clone using SuperDuper! and, as usual, it went flawlessly. (Side note: He could charge triple for that program, and I would pay)

Just tell me where to send the bill, Dan!

(via The Unofficial iMFAQ News—Thanks, Dan!)

My experience — the software backed up my 80 GB (actually available 74.52 GB) containing 42 GB of data (204,483 files) in I hour and 15 minutes, a time comparable to other products I have reviewed for macC. Hurray, it passed the ultimate test of the backup software. My backup booted when I selected it as my startup disk. If you can’t boot it up as a startup disk, the backup is less flexible. Nevertheless, you can indeed recover you user files from it. Buy it and switch — I did. Do it now, not yesterday.

(Via MacCompanion: Thanks, anonymous reviewer!)

Hey, look ma, no exclamation point in that title! Had to happen sometime.

So, the Safety Clone.

The Safety Clone is one of the most unique things that SuperDuper! does, but also one that is potentially misunderstood. I was really happy to see Ted Landau’s Macworld post suggesting it for Tiger, as it’s a pretty painless way of testing whether an OS upgrade works, but it’s important to understand what it is, and what it isn’t.

First off, the Safety Clone is not (not!) a “backup” in the conventional sense, so please don’t use it this way. We provide two scripts—“Backup - all files” and “Backup - user files” that are intended to be used as backups… hence their names. But the Safety Clone is something entirely different.

The idea is this: the Safety Clone isolates a copy of your system on its own partition. When you boot from it, you can install system-level updates (like Tiger) in this “Sandbox” while still retaining the ability to “roll back” to your original should something go wrong.

How do we do this?

Basically, the Safety Clone copies the “system” files that are considered to be “owned” by Apple: most of the things outside your Home folder. And, it shares those files that are “owned” by you.

For the more technically inclined, we “share” the files by symlinking them as appropriate. Details of what files are shared and what files are copied can be obtained by examining the script involved. If you have questions, ask!

So, we create two copies of your system—one in the “Sandbox”—but have only one copy of your user files, which reside on the original drive. When you boot from the Sandbox, you’re on an isolated system, but you’re changing your original user files. That way, when you boot back to your original OS, all the changes you made are there—because you changed the original files!

Just remember: it’s not a backup. It’s a checkpoint of your system that allows rollback of the OS. You must continue to back up your original volume if you want to protect against data loss. (Backing up the “Sandbox” isn’t usually necessary, since the things stored on it aren’t “personal”.)

Tips and tricks about “rolling back” in the next tedious installment!

First, I made a complete and bootable duplication of my PowerBook on a recently assembled 300 gigabyte external FireWire drive. In the past, I’ve used Carbon Copy Cloner for this task, but due in part to the fact that it hasn’t yet been updated for Tiger, I opted for Shirt Pocket’s elegantly simple SuperDuper! — I now happen to prefer it over Carbon Copy Cloner, anyway.

(Via Khoi’s great Subtraction blog, which kicks design ass: Thanks, Khoi!)

Wow, a lot of you are upgrading to Tiger! And I mean a lot!

Thanks to everyone who snagged a copy of SuperDuper! over the past few days: I really appreciate the registrations, and it’s great to see that you’re appreciating the program, too!

I’m in the middle of a post that talks about the origin of the Safety Clone and some tips, so stand by…

There are many excellent programs for “cloning” your drive. My recommendation here is SuperDuper! from Shirt Pocket. It boasts a unique Safety Clone feature that creates versions of your old (Panther) and new (Tiger) systems on two separate volumes. Both systems remain current with the files in your Home directory, so you can easily revert back to Panther if desired.

(Via Macworld’s Tiger Installation Guide—Thanks, Ted!)

To follow-up on yesterday’s post, the inevitable question is: how do files get like this in the first place?

As far as I can figure out, this floating owner “feature” is part of OSX’s OS9 compatibility, and also has to do with the “Ignore ownership on this volume” checkbox you’ll find in the Get Info window for non-boot volumes.

It’s important to remember that OS9 has no concept of ownership whatsoever. So, when a file is created by an OS9 application, running in OS9 itself, it has to choose a user that’s going to own the file.

But what user should it choose? As I said, there’s no real concept of ownership in OS9. And if you randomly just pick a user—say, the first one—there’s no guarantee that you only have one user on your machine… and no way to ensure that, once you’re in OSX, the correct user owns the file.

There’s a bit more complexity to this whole “user” thing. While a user has a name (the “short user name” you select when you first create the account), the system doesn’t really assign the “name” as the owner of the file. Instead, it uses a User ID, which is a number.

On OSX, the first user account created is given the User ID 501. The next account created is 502, etc. These numbers are what are associated with the files on your disk, not the short user name, which is more for your convenience than anything else.

This can create some confusing situations, though, when you bring a disk to another computer, and turn “Ownership” on. If it’s another user’s computer, and their account was the first created (most are), that means their User ID is the same as yours. So, your files will look like they’re owned by them!

Similarly, if you have more than one computer in your office (or family), and the accounts weren’t created in the same order, your account may be “501” on one machine, and “505” on another! (Here, to avoid this problem, I make a habit of creating all my accounts in the same order on all machines.)

No doubt this is why Apple allows you to turn ownership off when you attach a FireWire drive to your machine… this causes all the file owners to float!

So, Apple compromised. Since they couldn’t randomly pick a user, and they didn’t want to force permissions on OS9—which would cause serious compatibility problems—they did the next best thing. They made these OS9 files owned by “everyone”, all at once. In other words, they made the owner float.

When the owner’s floating, it looks like it’s owned by the user looking at it. So, if the file is saved in OS9 (or stored on a FireWire disk with “Ignore ownership on this volume” checked), it’ll be owned by whatever user looks at it.

Even if that user is a Backup program running as root, like SuperDuper!. Which brings us full circle.

Bruce and I had spent a long time designing, writing and testing SuperDuper!—as you might expect, backup programs need to be extremely reliable, and we worked hard to make that happen. And it’s trickier than you might think—there’s a lot of obscure stuff in HFS+ and its metadata, and getting all of the information copied properly is quite a job.

We released SuperDuper! v1.0 in January 2004. This is obviously a really tense time in the development process. No matter how much testing you do, no matter how thoroughly you plan your coverage, no matter how many Beta testers you’ve got, no matter how good they are, there’s always something that shows up once you release the software into the wild. Always. (Just ask Apple!)

Fortunately, we’d done an excellent job: early feedback showed we had no reports of any significant nature—most problems were quite minor and easily handled.

But there’s always something. Always.

In our case, over the first few months, we’d get an occasional report of a user who couldn’t access their own files when they’d booted from (or restored) a backup. Sometimes, they’d try to log in and end up with an empty Home folder. Sometimes, certain applications wouldn’t run.

Investigation showed that, in these cases, the files on the cloned volume were owned by root, even though—when we looked at the original files on the system—they were owned by the user.

Here’s a good opportunity for a short digression.

Unlike OS9, OSX’s file system has a concept of ownership and permissions. While this can sometimes make your system feel like you don’t own it any more, it’s a fundamental part of the underlying security model: something that we all benefit from, even when the details can feel arcane, infuriating or random.

All files on the system are owned by someone, and usually your own files are owned by you. System files are usually owned by the system, also known as root. Owners are also members of groups with names like staff and wheel, and a file has both an owner and a group.

In addition to a file having a concept of an owning user and group, it also has a set of permissions. There are three separate permissions for each file: owner permissions, group permissions and other permissions. The owner of a file can give each of these permission to read or write the files (in addition to other things, but you get the idea).

By default, files you create are readable and writable by you and no one else. And the system stuff—things you shouldn’t be able to touch—are usually owned by root and can’t be modified by a regular user unless they “authorize”: which is why you need to enter your password when you run a system update… or SuperDuper! itself.

With that in mind: back to the main post!

Since the files were owned by root, it meant the user couldn’t write (or sometimes read) them—which caused all sorts of trouble.

It was easy to “fix”—we were able to give the user instructions on how to use Terminal to reset the ownership of the files back to their own user—but the real question was: how the heck was this happening?

This went on for months. We tested and tested and tested and were completely unable to duplicate the problem, yet it still showed up every so often. We were able to help the few users who were affected by the problem, but we couldn’t find anything wrong with SuperDuper! itself—it passed all our tests, and was working on the vast majority of systems out there.

Finally, it happened to a user who was willing to spend a relatively long time on the phone, trying various things. In the middle of the call, as I had the user try various things to try to diagnose the issue, I hit on something that didn’t make sense. When the user looked at their files, they were—indeed—owned by them. But, if we looked at those same files as a different user, the same files were owned by that other user!

Needless to say, this was more than a bit of a shock. How could a file be owned by different people, depending on who was looking at it?

We didn’t yet know what the deal was, but I coined a term for it: floating ownership. And, I had a theory about what was going on.

Because SuperDuper! needs to get access to every file on the system, it runs as root: the only user with that ability. And if these weird files had their owner floating, it meant that when SuperDuper! looked at them, they’d be owned by… root. So when we copied over the ownership, instead of copying the file as the user saw it, we’d copy it the way that we saw it: as root!

Eureka!

It took some time to come up with a solution that worked, since OSX tries really, really hard to hide this whole floating owner thing from programs: all programs. Even Apple’s own tools—like ditto—don’t handle floating owners properly when copying files! But, after some thinking and testing I came up with an idea that worked: something called on-the-fly verify.

Idea in hand, Bruce implemented it, and we tested and released it in relatively short order… and then held our breath.

It was clear soon after that we’d licked the problem, with an additional benefit: we started getting many more reports indicating that SuperDuper! could successfully create a bootable clone where all other tools failed—a great, and unexpected, benefit of on-the-fly verify.