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!

Most of you probably don’t know about it, but I contributed to the OSX portion of Slim Devices’ Squeezebox — I wrote the Preference Pane, Installer… basically, a lot of the Mac-specific stuff. I’m happy to see that Dean, Sean and the rest of the team have come out with a brand new Squeezebox, and the thing looks smokin’! Really nice industrial design, with a beautiful metal stand and a new upright profile. Gorgeous fluorescent display; wireless (802.11g — acts as a wireless bridge, too) or wired; supports virtually every codec you can think of, including AAC, WMA, OGG, FLAC… the list goes on and on. The Slim Server component is open source, so you can mess around with it, or — since there’s a very active community — make requests and watch the whole thing evolve! Not to mention the neat Squeeze Network, alarm clock, visualizers, multi-player synchronization… the list of goodness goes on and on. Not to mention that the new features are even available to their existing Squeezebox 2 customers, who they continue to treat as first-class citizens. It looks terrific — if you’re interested in distributed digital music, you owe it to yourself to check it out. Great work, guys!

I’ve posted before about my personal “boat anchor” that keeps a Windows machine close by — Microsoft Money. There was just nothing close enough on the Macintosh to allow me to move. I was a bit more successful replacing another bit of business, though: my document manager. I used to use PaperPort/Pagis to manage my bank statements, receipts and the like, but neither product was available for OSX. (PaperPort had an old version of desktop that ran, kind of, under OS9, but it hadn’t been updated for years and didn’t work very well in Classic… and I wanted to avoid Classic if possible.) PaperPort’s sheet-fed scanner — the Strobe — was a really cool little unit that let you push a bit of paper into it. It’d turn on, automatically scan the paper, launch PaperPort Desktop, and place the scanned document there, all pretty easily. Pagis didn’t work quite the same way, but did do lots of other cool little things like automatic document orientation correction, OCR to allow searching of a scanned document while preserving its graphical appearance, etc. I found them pretty indispensable for years, as they enabled me to organize of the mass of paper that arrived — and continues to arrive — every month. But, the scanner wasn’t Mac compatible, so I had to buy something that was. The only duplexing scanner I could find with a sheet feeder, at the time, was by HP: the ScanJet 5590. At first, I tried to use its own ability to generate PDFs, but the thing generated absolutely huge PDF documents, even at low (200dpi) resolution black and white scans: we’re talking on the order of 25MB for a single, 20 page bank statement. And multi-page scans were a huge pain to knit together. Utterly unreasonable. It took a while, but I was able to find a similar product on the Macintosh — Dominion Software’s Working Papers. It wasn’t perfect, nor was it as elegant as either PaperPort or Pagis, but it did the job. Unfortunately, it was also plagued with a decent number of annoying bugs. And while the developer no doubt had the best intentions, it’s clear that the product isn’t in active development any more. Not to mention the fact that the scanner has bad drivers, especially in combination with Working Papers’ TWAIN handling. I was spending too much time mucking with drivers, working around crashes, skipped pages, unreadable scans… quite frustrating, and because of that, over many months , my system fell apart and paper began to stack up. Well, I’m happy to say I’ve found the solution. Fujitsu (Fujitsu?!?) has released a Mac-compatible version of their ScanSnap scanner, the memorably named Fujitsu ScanSnap fi-5110EOXM (affiliate link). This scanner does duplexed, color scans at 15ppm, has an excellent paper feed mechanism that doesn’t seem to jam, has a decent driver that doesn’t crash, comes with Acrobat 7, and generates excellent quality, well-compressed scans. And a higher resolution, multi-page, color PDF from it is smaller than the one-bit, black-and-white compressed scans, in a proprietary format, that I was getting from the HP/Working Papers combination. As they say, w00t! There are some downsides:

• It doesn’t work with anything but Acrobat, as the driver isn’t a standard TWAIN driver.
• The driver is a standard “application”, and occupies space on your dock when running.
• The Macintosh version only comes with Acrobat and the driver; the PC version comes with a full software suite including a standalone paper management application, business card reader thingy, and a $40 rebate, making it cheaper than the less-capable Macintosh version. The Mac version is white/aluminium, but it’s like putting a sock over the boot that’s kicking in your teeth. But at least they released the Mac version, so kudos for that.
• Scanned documents default to a single file location, with an automatically generated name, rather than being an untitled document in Acrobat that can then be saved to the location of your choice. So, it’s more awkward than it needs to be.
• Acrobat 7 is kind of slow doing OCR, if you want the scans to be searchable. But at least it’s possible!

But, they’re relatively minor points. The ScanSnap is an excellent unit that I highly recommend to those who need to do — or have considered doing — document management.

As two of you know, SuperDuper! has provided an AppleScript interface for some time. We’ve used it to provide the rudimentary scheduling in the v1.x series, and we’ve enhanced as necessary to improve the experience in v2.0. But, one rather tricky thing fell out during the process: users can (and will) schedule any number of backups in ways that might overlap, or even start them at exactly the same time. And, given the nature of a multi-processor machine, and the fact that each “scheduled job” is an AppleScript external to SuperDuper! that has no knowledge of the other scripts around it, there had to be a way to serialize execution or the scripts would all interfere with each other. In the v1.x series, we’d put a rudimentary system in place: the script can ask about the current status about SuperDuper! and — if SuperDuper! is busy running another copy, it’ll say just that, and the script just waits until it’s done. This was mostly done to prevent the script from “grabbing” the interface away from a user who’s actively using SuperDuper!. But, with v2.0, it’s trivial to schedule two copy jobs for the same time, and with the old technique both could be told that SuperDuper! was, indeed, idle. And then, both would try to run at the same time. Clearly, it’s unreasonable to ask users to schedule their own backups in a way that would take this into account: we had to handle it internally.

Of course, another way to handle this is to break SuperDuper! into a true background engine, and have the UI and scripts all “drive” this process (or processes). But, beyond breaking existing scripts, doing so required enough reengineering to push it well beyond the scope of this particular release, much as it would have been cool. Gotta ship sometime, you know?

So. Bruce and I talked about this for a while, and Bruce came up with the idea of just changing the status into a queue. The first process who asked for status is at the front, and only the guy at the front gets the real status at any given time: every other script always gets “busy” until they move to the front of the queue. Nice, simple solution and — apart from various tricky bits that always plague any solution — it seemed to do the trick. Which led to another problem. To try to match user expectations, the scheduled jobs try to leave SuperDuper! in the same state it was in when they started. So, if SuperDuper! is running, we leave it running; if not, we quit when we’re done. The scripts are responsible for this state preservation. And, once again, when launching at the same time, on fast systems both would see SuperDuper! as not running, and would take responsibility for quitting. To avoid quitting the application out from under the others, each would be waiting for the other script to finish… and then, due to the deadlock, SuperDuper! wouldn’t ever quit. Great. More discussion, and another simple solution: the quit command basically waits until the queue is empty, and all external processes are done, before it does its thing. And this simplifies the scripts, too, because they just don’t have to worry about it. And, all without changing the script dictionary… not too bad! So, we’re sweating the details here. Or trying to.

Hey, looks like Jonas Salling has released Salling Clicker 3.0, with both a Macintosh and Windows version! Very cool — here’s hoping that one of the hardest working men in shareware gets lots of new customers.

Looks like Rich Siegel, of BBEdit fame, has started blogging. And he’s ragging on bad drivers! Go Rich! (And don’t miss the great Oktoberfest Special they’ve announced over at Bare Bones. $99 is an incredible bargain for the exceptionally well regarded editor… if you’re even remotely thinking about snagging a copy of BBEdit, now’s the time!)

Yeah, OK, so the technical definition of a Beta test is that it’s feature complete. But, that’s not how I’ve ever really done it. I consider a Beta a build sent to external testers that’s stable and usable. And, SuperDuper! v2.0 has been in this type of testing since November 22, 2004. Yeah, that’s right. We’ve had 70 external testers pounding on v2.0 since last November. The testing has been going great, with very few problems reported, especially considering how much has been changed over the months. And I’m happy to say that we reached an important milestone yesterday: the last new feature of v2.0 was finally released to our external testers. We’re feature complete. Things are working really well. I feel like I’ve been at sea for a year and have just sighted my first gull. Land can’t be far away!

As a long time Mac user (since 1984) a have one really big complaint about MacOSX, and that is the incapability of the Finder to easily copy a bootable System folder to an external disk and boot from there. Enter SuperDuper!, a 20$ software for MacOS X, that allows you to copy entire disks, even in the unpaid version. The paid version has tons of additional features, but all with a really easy and understandable user interface. Highly recommended and compatible with MacOS X 10.4, too.

via teddythebear: Thanks, Mr. Bear!

Given the amount of traffic he’s been getting, I’m not sure he needs another plug from me, but Shaun Inman’s Mint is a terrific new webstats package that focuses on clear presentation and extensibility. Mint’s a framework that supports a plugin architecture called Pepper, and there’s already a vibrant 3rd party community doing great things with it. Mint’s not perfect: it requires a teeny bit of Javascript on every page to do its magic, had some problems in its initial release, and its side-by-side panel presentation doesn’t always make good use of space (which it sacrifices for consistent layout). But, that said, the overhead is minimal, the configuration (now that he’s past the teething stage) is easy, and the information provided is invaluable. Great stuff; recommended to those with a commercial web presence.

Right after Tiger arrived on my doorstep, I went shopping for a firewire harddrive. I waded through a ton of reviews and finally settled on an OtherWorld Computing Mercury harddrive. So far it’s working very well. Although I could have used the included Retrospect program, I opted to go with a shareware program named SuperDuper!. And that was probably one of the better choices in software I’ve made. As soon as I used it, I knew it was worth every penny of the shareware price (which I immediately paid). Sometimes, I look at a piece of software and have a debate about whether the fee is worth it, whether there might not be something out there that’s freeware or open source, whether I’d rather just use something that’s produced by one of those big software companies…but there was no debate about this one. I fired up this app and just knew.

via Ms. Cranky Pants Techie Geeky Mac Stuff (Thanks, Alice!)