We've received some independent confirmation that the version of Snow Leopard we've been testing with these past few weeks is, indeed, the version that's shipping to users. So, at present, and as promised given those circumstances, I expect v2.6 of SuperDuper!, which is fully Snow Leopard compatible, to be released Friday, day and date with Snow Leopard.

SuperDuper! itself will detect and download the new version (unless you have that preference turned off), and you'll be able to download it from the usual links as well, when released.

Although the testing is not quite complete, I want to take a moment to thank all of the external testers who have been working with various builds of v2.6 since over a year ago, when the first external beta was released: without your efforts, we wouldn't be able to get the kind of coverage needed to help certify a release, nor the kind of feedback we need to confirm we're on the right track.

So, barring any last minute disaster, it won't be long now...

Yeah, it's a gigantic, multi-day blast of blogging here at Shirt Pocket World Headquarters and LEGO Assembly Center.

I'm going through the revision history for the betas as I try to determine what's best to highlight, and there are a lot of behind-the-scenes changes in this version. A few more fun new features:

1. PGP Whole Disk Encryption (PGPWDE) now supported for source and destination
   This is not one of those things that'll thrill the world, but many users want a bootable, fully encrypted source and destination. SuperDuper! v2.6 understands how PGPWDE stores its data, and supports encrypted sources and destinations, so the notes from your mom and lists/photos of assembled and painted Gundam models are secure!

2. (Much) Faster Disk Image mounting
   Back in Tigerdays, a security update changed image mounting to scan the image before mounting it, in case it's damaged in a way that can cause a security problem. But with an image that you're using for your backups, the scan doesn't really help, since you didn't get the image from a 3rd party. We've used a new "don't scan" option where supported... which makes image backups much faster.

3. Countdown to completion actions
   If you tell SuperDuper! to Sleep, Restart or Shutdown when it's done, but you're using the Mac, there's was previously no way to stop it: at the end of the backup, it was time to go sleepy-bye (or whatever), with no arguments or stalling. We now put up a sheet that allows you to cancel this after-copy action if desired. If only life were so simple.

4. Sparse Bundle support
   For Leopard and Snow Leopard (10.5 and later) users, we now directly support the Sparse Bundle image type, which further speeds up network and other image-based backups.

To remind people again, since it's a question I get asked all the time, and as has been true since v1.0 of SuperDuper! was released back in—what—2004 or something, it'll be another free update.

Hopefully that's enough to further whet your appetite; back to cooking.

Hey, everyone! So, as promised in my previous post, we're working hard on getting v2.6 out, which will include full Snow Leopard support.

Over 140 people are currently testing the current Beta, and save for a few relatively minor problems things have been going very well.

I had based our general schedule on the typical "shipping in September means September 32nd" Apple schedule, but it seems that this time Apple's decided that "shipping in September" means "shipping in August". Go figure.

We're working as fast as we can to get our testing done so we can get the new version out to you. And it doesn't just have Snow Leopard support in it. A few things we've added:

1. Backup on connect
   When you click Schedule..., you can either schedule a timed backup, or tell SuperDuper! to back up when a given drive is connected to your Macintosh, or both.
2. Eject after copy
   You can now set an "On successful completion" action to eject the destination drive after the copy has been completed.

By combining those two options, you can set it so that SuperDuper! backs up a drive when you connect it, and then ejects it when done. Pretty convenient!

Of course, we didn't stop there... more later! Back to testing!

(Sorry that I've turned comments off for this post. Last time we released an update around the time of an OS release, my server got totally overloaded/whacked sending out blog responses to everyone who commented. It's not that I don't want to hear from you—feel free to head to the forums or send email.)

I've recently been getting a lot of questions about SuperDuper! and Snow Leopard compatibility, so I thought I'd put an "official statement" (oooh!) up here on the blog.

Remember: Snow Leopard is under Non-Disclosure. I can't really say anything about it until it's released. So, please, don't ask. You'll get mad at me for being vague, and I'll get tired of it too: it's a lose-lose.

We will be supporting Snow Leopard as soon as we possibly can, and we're already working on it (of course). If Apple releases the "production bits" to developers before they release them to the public, we should be able to do our final testing before release.

I do not anticipate or expect a Leopard-style struggle to get our Snow Leopard support finalized. This will disappoint no one, especially not me.

And, no, SuperDuper! under Snow Leopard is not going to be 64-bit: it doesn't make any sense for this type of application.

For those who might be using Snow Leopard now, and are getting an error referencing fsaclctl: you can copy fsaclctl to Snow Leopard from Leopard (it's in /usr/sbin/fsaclctl) for now.

Everyone clear? Good!

I'm not going to make a commitment to blogging more this year, although perhaps I should, because I've been remiss (and busy). I am up on Twitter as dnanian, though, so feel free to follow me there for the occasional self-serving and usually uninteresting bit of blather.

The New Year is starting off well with a great episode of MacMerc TV featuring SuperDuper!—big thanks to Rick Yaeger and his crew for the cool video!

And—just noticed—it looks like we're featured on the New York Times Podcast, too. Nice!

Anyway, I just wanted to wish our customers and friends a very Happy New Year - you're appreciated more than my relative blogging silence indicates.

Thanks, everyone!

Excuse the brevity of this post, but—as you might expect with a new update–things are kind of busy around these parts.

The update's gone well, except for some bandwidth issues we had to deal with, and some MySQL issues on my server that happened due to some issues with the way FogBUGZ handles large attachments (really, really crappily, typically crashing MySQL after eating huge amounts of memory). But, apart from continued delays for outbound mail due to volume, it's good.

But, as I said a number of posts ago, the only thing I can promise about a big update like this one is that there'll be a few problems. They're not affecting many people, but to summarize:

• Some users are reporting that the status display stops updating in the middle of the copy. The backup does actually complete eventually, but the progress bar doesn't move, and the file counts stop.

  We're not quite sure what's going on here: it's not something we've been able to reproduce at this end. But we're looking into it. If you're experiencing this issue, drop a note to support.

• The updater has been giving the occasional problem. This is frustrating, because we know of some problems there and have tried to "pre-emptively" handle the problem with the update notice, which indicates that you should download the update manually if you experience a problem.

  Unfortunately, that hasn't been clear to people, resulting in a huge volume of incoming mail (we're talking thousands in the past few days)... so sorry for the delays in responding.

• 10.2/10.3 users were being offered the 2.5 update. Due to an error in the update description XML, 10.2/10.3 users were being offered the update, even though it wasn't compatible with their systems. The XML has been corrected, so that shouldn't happen any more.

• Some users are having problems starting up from their copies. On some systems, copies start up but then programs immediately begin crashing. This is corrected by re-prebinding the copy, but given the way Leopard works this shouldn't be necessary. We're hoping this is a Leopard bug that'll be corrected in an update of OS X, but we're investigating it here, too.

• Users with AntiVirus programs are having the occasional problem. This is kind of expected, given the way that AntiVirus programs work. In general, we suggest that you configure your AntiVirus application so that it ignores the backup volume.

  That said, if the AntiVirus program is on, an incorrect result code returned from a system call is indicating a file that vanishes between two points of execution is a folder, when it's not, and that's causing a weird "(null)" error that repeats a large number of times in the log. We're implementing a workaround for this case in our copy engine.

  Note that if you get a "permission denied" type of error and you're running AntiVirus, you should configure your AntiVirus program to not scan the backup volume, or turn off its "auto protect" feature while you're backing up.

• Already mounted images, or images with special characters in their filename, cause an error. Due to a regression (caused by an attempt to workaround another bug), SD! fails if a sparse image we're supposed to copy to is already mounted. We also fail if the image has "special" characters (such as a quote) in it. We're working on a fix for this.

• Networked Time Machine backups, on the same volume as local Time Machine backups, aren't preserved. If you're using the same volume for "networked" and "local" Time Machine backups, and you try to store a SuperDuper! backup directly to the same volume, we preserve the "local" backups but not the "network" ones. (That's a mouthful, sorry.)

  We're working on a fix for this as well.

• Custom copy scripts that used "Exclude spotlight files" are failing. This script is no longer needed, so users who have included it should modify their copy scripts to remove the reference.

I think that's about it. There's nothing terribly major in there, fortunately, and we're working on getting the problems corrected as quickly as we can.

Thanks to everyone who's reported problems, and also to the vast majority of people who haven't encountered any!

And what could make it more official than a press release and a download?

Press Release

Shirt Pocket is happy to announce that SuperDuper 2.5 is now available as a free update for all users. The new version includes full Leopard support, including the ability to store a bootable backup side-by-side with a Time Machine backup on a single volume, and the ability to copy Time Machine archives to other drives for backup purposes or to move to a larger drive without losing history.

In addition, version 2.5 improves many aspects of our 2005 and 2006 Macworld Eddy-award winning application, including improved Spotlight handling, a "Run Now" feature for scheduled copies, icon preservation for destination volumes and various performance improvements.

"What more appropriate day to release a terrific new version than SuperDuper Tuesday? We're really happy with the way version 2.5 works with Leopard", said David Nanian, owner of Shirt Pocket, in his standard stump speech. "Our new feature set is great on its own, plus it's an excellent complement to Time Machine, adding the ability to have a bootable backup alongside your Time Machine archive -- and we've done all this without any increase in complexity. With SuperDuper!, recovery from a disk crash is just a matter of rebooting from the backup!"

Of course, SuperDuper 2.5 still has all the capabilities SuperDuper! is famous for, including: the ability to easily schedule backups; additional imaging options; more control over shutdown; better AppleScript support; hundreds of UI improvements; Growl support; and a readable, complete, task-based User's Guide.

SuperDuper supports both Intel and Power PC Macs running Mac OS X 10.4 or later, and is a free update for existing users. The unregistered version will perform full backups for free. Registration costs $27.95, and includes many additional timesaving features, including Smart Update for faster backups, Scheduling, and others.

More information, as well as a download link, can be found at http://www.shirt-pocket.com/SuperDuper.

About Shirt Pocket

Shirt Pocket, based in Weston, Massachusetts, was formed in late 2000 as a Macintosh-only shareware creator and publisher. Shirt Pocket's first product, the 2004 Eddy Award winning netTunes, lets customers control iTunes on one Mac from any other Mac on the network with iTunes own intuitive user interface. launchTunes, Shirt Pocket's second product, made iTunes' playlist sharing practical by automatically launching iTunes on remote servers when needed. SuperDuper!, the 2005 and 2006 Eddy Award winning disk copying program that allows mere mortals to back up and restore their systems accurately and confidently, was released in January 2004.

Shirt Pocket was started by David Nanian, co-founder of UnderWare, Inc, and one of the original authors of the BRIEF programmer's editor and Track Record bug tracking system.

...we salute our testers, and the patience of our users.

It's going to be a SuperDuper! Tuesday.

A few days ago, we were happy to get a workaround for the bug mentioned in a previous post, so we went about implementing and testing—and things were working quite well.

Unfortunately, we've found a case where the workaround doesn't, um, work. I think I have a way of dealing with it, and so we're going to implement Workaround Part IV: The Reworkening and run it through the wringer.

Again.

These tests are really time consuming, as you might guess: it can take eight hours to rebuild a complex-case volume (so I try to keep one building while another is testing), and then more hours to run the test. I can't begin to tell you how frustrating it is to have a set of simple tests work and then find that the thing we found rearing its ugly head again in another (more complex) scenario that can (and did) happen in "real life".

This is why we don't just implement a fix and release, of course: we want to ensure it works before we toss it out there, and so we smoke test, test internally and then—if internal tests are OK—test externally, every time. We always are hoping for green lights at every stage. Sometimes, 99% of the way there, you get red. Then, the failure needs to be investigated, understood, reproduced...

Anyway, we'll leave that between me and my ulcer. If my new idea works, this will hopefully only delay things a few days, which will be plenty of time to fill the comments with complaints of our laziness, incompetence, lack of communication and general suckitude. Have at it!

Note: I've had to turn comments off for a little while because the subscriptions to comments are overloading my outbound servers (every time someone posts something, it's sent to the 200 people above their post), causing delays for regular support mail, etc. You can still review existing comments by clicking the title of this post. I'll turn them back on after the backlog clears. Sorry for any inconvenience: it's not that I don't want to hear what you want to say...

Last post, I mentioned that we were bitten by a bug that showed up during late-in-the-game testing that didn't make a lot of sense, and was quite nasty in certain complex situations. This bug caused the "release process" to grind to a halt.

Well, I'm happy to say that, as of about two minutes ago, I've managed to figure out what's going on.

Basically, a folder can become "magic" in some situations, and even when the conditions that made it "magic" are reversed, the "magic" sticks around when it shouldn't. Unfortunately, this "magic" acted as a sort of "protective spell" on the folder, and was preventing us from doing anything.

Unfortunately, there's no 'external' visibility for when the "magic" sticks around, so we were seeing something that basically didn't make any sense. On top of that, it's new behavior in Leopard, which is why we've never seen it before. Fortunately, thanks to Amit Singh's recently-updated-for-Leopard hfsdebug (thanks, Amit -- love the book, too), I was able to drop down into the guts of HFS+ and determine what's happening.

Now that the problem's understood, we can implement an effective workaround. The workaround will mean that in some situations it'll re-copy a bit more than it should when Smart Updating. But, at least the result produced will be correct: and the workaround will break the spell, and remove the "magic".

Which is—let me tell you—a relief. (For those of you out there who have hit this kind of WTF-roadblock, where you have no idea what's wrong and thus can't even estimate how long it's going to take to figure it out and fix it, you know what I mean.) And for any Apple engineers reading, the (incorrect) behavior is described in rdar://5687977.

So, anyway, now that that data-integrity-related bug is getting wrapped up, we're back to putting together a final test build (should be in the next day or two), a bit of time to let our test group run their scenarios, etc.

So, barring another similar issue (please, no) showing up during testing, as I indicated in the comments of the previous post, it should be a week or so...