Every day, I get asked one question over and over—namely:

My backup is failing, and it’s saying that it couldn’t disable ignore permissions! What’s going on?

This started the day Tiger shipped, and has continued on a hundreds-of-times-a-week basis since. And the worst part? It’s a bug in Tiger. So, put on your waders—we’re going in, hip-deep.

Basically, here’s the deal. OSX has a file called “volinfo.database”, which is stored in a normally-hidden-from-you folder named “/var/db”. It’s a simple text file that looks something like this:

290AC3DC4B28C8FC: 00000001
9A081A3451A451C7: 00000001
435F42E92DC994B5: 00000001
C3301F4FEBB1BC41: 00000001
F36BADBD7ACFBD6F: 00000001
AB47F9CD780BF0A8: 00000001
76E8B50DFBBBD9BB: 00000001
893D1C0A293603C7: 00000001

(That’s my real one.)

That looks like gobbledegook to most, but it’s really a database of the volumes you’ve got connected to your Mac, listed by UUID (a low-level internal identifier that’s constant, even if you rename the volume), followed by the state of their “Ownership” flag: 0 if ownership is off, 1 if it’s on.

When you attach a new drive to the system, the UUID of the drive’s volumes are added to the database, along with their “ownership” setting. And, when you check/uncheck it in Finder’s Get Info panel, the value changes here, too.

Apple ships a command-line tool, vsdbinfo, that allows programs to check and adjust the ownership state of a given volume.

It’s very important for SuperDuper! to ensure that ownership is turned on when it makes a copy. If it’s off, the system does strange things with the file’s owner and group (see Floating ownership nearly sinks us for the story of that particular horror). So, we check it, with vsdbutil, during the “preparation” phase before starting a copy.

Which brings us to Tiger. When Tiger installs, it goofs up when it manipulates this file. So, instead of what you see above, you get:

290AC3DC4B28C8FC: 00000001
9A081A3451A451C7: 00000001
435F42E92DC994B5: 00000001
C3301F4FEBB1BC41: 00000001F36BADBD7ACFBD6F: 00000001
F36BADBD7ACFBD6F: 00000001
F36BADBD7ACFBD6F: 00000001
F36BADBD7ACFBD6F: 00000001

I’ve looked at hundreds of these at this point, and it’s pretty clear what the problem is: the installer, or something it runs, has neglected to put in a carriage return. Two lines run together, and the system can’t parse the database any more—so it always says that ownership is disabled, even when you try to turn it on. (In the case above, one volume has multiple entries because the system keeps failing to turn ownership on… even though it’s doing the right thing, the very fragile parser can’t move beyond the bad line.)

It’s a really simple bug. And while I’ve reported it, it hasn’t been fixed. We’ve waited, provided our users with a workaround, and waited, and waited… and it’s just not getting fixed.

This is really frustrating for our users, because things don’t work in a mysterious (and ungrammatical) way. And it’s frustrating for us, because it makes us look bad, incompetent and/or lazy. Honestly, we’re not.

So, since it’s not getting fixed by Apple, we decided on an alternate approach. I did the research necessary to ensure the problem was consistent, and to figure out how we could fix it for them. After looking at hundreds of these, and confirming that the problem is as described above, we’ve integrated a fix into v2.0.

Specifically, we examine the structure of this text file. If it’s missing the carriage return, we correct it, leaving the semantics intact (all volumes with ownership on/off stay the way they are).

In our testing, this solves the problem 100% of the time… and I, for one, won’t miss directing people to the FAQ entry that, as of this writing, has been viewed 5325 times since April.

I’m sure our users will be much happier, too!