The worst part about OS updates is that we can't talk about them.

I know other companies will sometimes discuss Apple's next version of OS X, and how they do or don't work with it, but we try to keep our mouth shut until it's actually out there and we're released from our non-disclosure.

That day is tomorrow, as I write this, and today, as I post it.

So let's talk about Mountain Lion and SuperDuper!

SuperDuper! is already Mountain Lion compatible

The version of SuperDuper! that was released last year, v2.6.4, was already compatible with Mountain Lion, with three exceptions:

1. SuperDuper! v2.6.4 is not signed, so it will get flagged as a scary-bad application with the default Gatekeeper settings. It's not, of course, and already installed copies of SuperDuper! should work fine.

2. Automatic mounting of ejected local volumes for scheduled copies does not work.

3. Most of you can ignore this, but for the technically inclined: while SuperDuper sandboxes work, sandboxing of Mountain Lion (for future Mountain Lion updates) doesn't copy the applications Apple added to Mountain Lion (e.g. Messages, Notes, etc).

SuperDuper! v2.7 is more compatible with Mountain Lion. Plus it's even better.

I'd love to say that we've been sitting around sipping Corpse Reviver #2s and relaxing full time since the last update. That would be pretty awesome, but, well, no.

Instead, we've been working to make SuperDuper! better in a bunch of significant ways, which include:

• Faster file copies That's right, your backups will finish faster than before.

• Better information during copying We now update the status window while large files are being copied, so you can get a better idea of what's going with your backup while you sit back, relax, and have a tasty beverage of your own.

• Gatekeeper compatibility SuperDuper! is now signed, and will not generate Gatekeeper errors when installed with Apple's default settings.

• Much faster startup SuperDuper! starts even faster, even when you have unresponsive network volumes attached.

• Better copying of active files Applications that rapidly create and delete files during a backup no longer cause intermittent "vanishing file" failures.

• Better handling of Time Machine As much as we wanted to copy the local snapshot (the .MobileBackups folder), it was in an uncopyable state too often. It's now ignored, which results in fewer backup failures.

• Improved diagnostics We've worked around problems in Lion's (and Mountain Lion's) file copy APIs, and more accurately return errors when drives can't be read or written.

• Support for Growl's latest version & Notification Center We now support the version of Growl in the Mac App Store, which means we also support its latest features, including Notification Center.

• Still supports Intel and Power PCs; OS X 10.4.11, 10.5, 10.6 and 10.7 As crazy as it seems (and as much as a pain it's been), we still support versions of OS X released in 2005, and Macintoshes that that should have been made into fish tanks years ago.

  In other words: we, clearly, are not smart, and those of you with older systems benefit!

• Various other miscellaneous improvements Because we can't help ourselves.

Wait a second. You said "more compatible", not "fully compatible"!

You spotted a weasel word! Well done! Nothing gets past you, clearly.

Automatic mounting of local volumes is the one thing we couldn't get to work in time for Mountain Lion's release. (Backup on connect still works just fine.)

Basically, Apple is tracking where an application launches from, and seems to be preventing processes that launch from "cron" (one of the system schedulers), even indirectly, from mounting local disk volumes, even when that application is signed.

We found this late in testing, and tried valiantly to try to work around it, but were unable to in time. And given that it's undocumented (but really cool) behavior, I just couldn't justify holding up the release of v2.7 based on this one problem.

Don't lose hope, though: we're think we know how to fix it—initial testing looks good—so we'll release another version of SuperDuper! as soon as we get the fix fully implemented and tested.

How do I get the new version?

Start SuperDuper! and it will prompt to update itself (unless you've turned that off), or install it manually from the download at the SuperDuper! page at Shirt Pocket.

Yeah, but how much does the new version cost?

That's always the way, right? Show me the money, etc.

Well, we've never charged for updates, not since SuperDuper!'s release in 2004. Not once. And we're not raising our prices.

The update is free. A SuperDuper! registration still costs $27.95.

And the unregistered version still never expires, will make full, bootable backups, and comes with support.

We know it's not the most profitable way of handling things. But as long as you—our users—continue to run, love and recommend SuperDuper!, we'll continue to do our damnedest to do right by you.

So there you go: thanks for reading this and for using SuperDuper. Enjoy the new version!

It's been in test for quite a while, and we're happy to say that SuperDuper! v2.6.2 has been released!

I understated the speed improvements we've measured in the press release and collateral, but we really are seeing 3x improvements in-house, which is pretty great. We'll see how it works for you.

Anyway: I hope you enjoy the new version as much as we enjoy being able to provide it to you.

Just a quick post to let you know how things are going with SuperDuper! and the upcoming v2.6.2 (no release date yet, so don't ask—hence this post). So far, we've:

• Implemented a fix for the problem where we don't preserve compression under Snow Leopard
• Ensured that extra data is no longer copied with back-to-back Smart Updates (as expected, a side-effect of the compression issue)
• Resolved the various other issues mentioned in the last post (although we haven't come up with a fix for the scheduling/settings issue yet)

These fixes have been in external testing for over a week, and the feedback has been excellent so far.

Since we hate releasing updates that have nothing but "fixes" in them, in addition to the above, we've made some changes that significantly speed up the speed of copying, with both Smart Updates and full copies.

In our internal tests, confirmed by our external testers, copying under Leopard and Snow Leopard (with larger data sets) is up to (wait for it) three times faster, especially with fast destination devices.

Needless to say, both of these changes involved "cracking open the cloner", which requires significantly more testing than a tweak to the UI or some "simple" changes to higher level aspects of the copying process, but progress is very good and we're looking forward to getting this into your hands as soon as we (and our external testers) are satisfied with it.

Note that I'll be at C4 this weekend, so support might be a bit slower than usual from Friday until Monday. If you're at C4 too, say Hi!

Well, a week has gone by, and 2.6.1 has been downloaded and run by an awful lot of you. It seems to be working well, too—which isn't to say it's perfect so, once again, no unicorn.

Here's what we're working on right now.

Individual file compression under Snow Leopard is not maintained on the backup

This kind of caught us by surprise, frankly. When we checked our copy results, we found that the sizes of files were the same on source and destination, and assumed the files were, indeed, being copied with compression.

Nothing like an assumption to make one feel like an ass. Or an umption. Whatever.

Anyway, what's happening is the OS is hiding the compression from us... and we didn't realize it. For the nerdly among us, here's some terminal commands and output that you'll find interesting:

$ ls -l /Applications/iCal.app/Contents/MacOS/
-rwxr-xr-x  1 root  wheel  9123088 Jul 16 03:42 iCal
$ cp /Applications/iCal.app/Contents/MacOS/iCal ~/iCal
$ ls -la ~/iCal 
-rwxr-xr-x  1 taiko  taiko  9123088 Sep  4 17:16 /Users/taiko/iCal

OK! So, I copied a file, and as you can see, the size of the file is the same when I started and ended: 9123088. This is what you'd see with SuperDuper!, too (except with the ownership and stuff preserved). So, everything's cool, right?

Well, no. At a lower, block level:

$ du /Applications/iCal.app/Contents/MacOS/iCal 
6776 /Applications/iCal.app/Contents/MacOS/iCal
$ du ~/iCal 
17824 /Users/taiko/iCal

Well, look at that: iCal, despite being copied with a system tool, is now nearly 3x the size in blocks after being copied, but the same size at a high level.

Great.

Needless to say, that's why we got confused. The sizes were the same. But they weren't... and you could only tell by looking at the amount of space the files took on the drive, not the file's size.

Note that cp, tar, Finder, etc all behave the same way with this: the file ends up getting expanded. The only one that acts differently, when given special parameters, is ditto, and that's likely because it's used by the installer (which puts these files on the drive in the first place).

We've got a good handle on this, and we're in the process of modifying SuperDuper! to retain the compression in the next update.

Some files get recopied every backup

We're aware that some files (specifically, files in /Applications, /System and /Library) are being recopied each time you back up, which significantly slows down repeated Smart Updates.

Our initial investigation has shown that while we thought this was related to prebinding, this is actually related to the compression issue, above. Specifically, compressed files, when they expand during copying, compare differently with flags and with certain time fields.

We didn't catch this because our confirmation tests didn't use compressed files. We did know that we were recopying files, but due to the fact that the end result was fine, and Snow Leopard shipped four weeks earlier than we expected, we just didn't have time to investigate the problem fully, especially since fixing it would involve the most critical and most time consuming to test part of SuperDuper!—something that we'd frozen many weeks before.

In other words, considering the issue was basically one of performance, we thought it was better to get the update out day-and-date with this known issue, than hold it back for the week or so it would take to investigate and fix (and then however long it took to test, based on what we had to change).

This should also be fixed in the next update.

Slower performance

We've had some reports of slower performance in the new version, which is more than a little weird, since the base-level copy calls are the same. Part of that is due to the re-copying, above, but we're looking into it further to see if there has been a regression, and if so we'll fix it as soon as we confirm and find the cause.

People aren't recreating their schedules

This version of SuperDuper! requires that people recreate their schedules due to some problems reading in parts of the old settings files. Many users aren't doing this, so we're trying to improve our error handling to detect and force the schedule to be recreated, rather than just asking people to do so.

UTF8 encoded URLs in AppleScript bite me again

So I'm an idiot. I can't tell you how many times I've attacked this specific problem in AppleScript, but I blew it again in the schedule driver in some cases, so drive names with some unusual characters (accents, etc) won't always run when scheduled.

Again.

I've already fixed this problem and it should be in the next update. It's been tested with both regular Unicode characters (e.g. ) and composed sequences (e.g. é). Note, though, that I haven't managed to get AppleScript to work with a drive named using the Alpha character (α) with backup-on-mount (reported by Glenn—thanks), because Finder fails when I try to use that character in a built-up path. Anyone who's awesome with this stuff in AppleScript please contact me if you have any ideas, because I'm fresh out.

Japanese users and backslashes

Back in the days of Panther, there was a weird bug where backslashes () didn't work in AppleScripts, because they were confused with the Yen symbol when you were in Japanese language mode.

That was supposedly fixed in the compiler back then... but in Snow Leopard, the problem seems to be back (it works properly in the Script Editor but not in the command-line compiler osascript), and I used some backslashes in the updated schedule driver. That's been fixed as well—thanks to Tohru for reporting the problem.

I think that just about covers the issues we're working on right now at a high priority... back to it.

Rather than taking the time to write a mildly amusing "we suck" press release that announces this day-after-the-big-release update, let me just say it fixes the stuff I mentioned in the last post, followed by ringing a dinner bell.

Come and get it!

It seems I always have to do one of these hey we released a new update and here are the two or three problems users have run into posts, no matter how long we test for, or how clean we think the build is.

Wouldn't want to break with tradition. That would be wrong.

So, hey—we released a new update yesterday: SuperDuper! v2.6. Perhaps you've heard of it? Well, there are a few problems users are having with the build, so here are some quick mentions of what we know about and our plans.

Problems enabling permissions/checking ACLs under 10.4.11

This is probably the weirdest one of all, because it doesn't happen on any of our 10.4 test machines (see the Cry of the Developer novel, coming to a technical bookstore near you).

We use the fsaclctl command-line tool to check the state of ACLs under Tiger and Leopard (although not under Snow Leopard, since it was removed when ACLs were permanently turned on). We did this in v2.5 as well, although there was a logic problem that caused us to not turn ACLs off on a destination if they were off on the source.

Well, curiously, fsaclctl, when used to turn ACLs off under Tiger on some systems, actually generates a low-level I/O error and fails. The curious and Tiger-y can try this with:

sudo fsaclctl -p /Volumes/some-volume -d

and some of you will see that it gives an error. Of course, only some, and all of you have already contacted me, it seems.

Anyway, since we can't really fix fsaclctl, we're working a fix-by-optimizing: we will no longer re-disable ACLs if they're already disabled and vice-versa. If you're using v10.4.11 and you're running into problems, you can use SuperDuper! v2.5 until we get the fix out (which shouldn't take too long).

Those damnable quotes

Ah, we fixed a quoting problem very early in v2.6's development cycle and—all smug like—patted ourselves on the back and moved on.

Alas, while we were moving on, we were scattering new quoting issues throughout some new parts of the code... and somehow missed them. But our users with volumes with quotes in them didn't!

The temporary fix for this is to rename your volumes and remove the quotes. You can put them back when the next version is released, so keep them safe.

Schedule recreation required

Although I put this in the release notes and in a FAQ, many missed it: to get the benefits of the new scheduling features, and to ensure compatibility with v2.6, your scheduled copies should be deleted and recreated.

Frankly, we'd love to do this for you. But we're concerned that users who have customized their schedule driver would end up losing data if we updated the internals "automatically"...

Very infrequent and bizarre ownership issue on Leopard

We've had two or three people who have been unable to get v2.6 to acknowledge ownership is enabled on Leopard.

We reworked ownership checks back during Snow Leopard's development when they removed the vsdbutil tool that we used to use, and decided to use AppleScript instead, asking System Events to get and set "ignore ownership" for the volume.

During testing, we found that System Events needed root permission to actually set ignore ownership, even though we were running an authenticated task, and would prompt non-Admins when it needed to be changed. At around this same time, Apple decided to put vsdbutil back into Snow Leopard, and so we moved to using it to set ownership, and scripting to check.

This went great during testing, but in the field, the scripting check isn't working for a few users. We have no idea why, but we're going to move back to a full vsdbutil-based approach (as was the case from v1.0 -> v2.5) until we can determine what's going on, or we come up with a better solution.

We kant spel

Yeah, the very last build renamed a button (from "Reboot Now" or something like that to "Restart Now"), which got fumblefingered to "Restar Nowt", because we're clever, detail conscious geniuses who were attempting an obscure and inaccurate reference to The Adventures of Buckaroo Banzai and blew it. We've corrected this to "Restarté Nowté" as was always intended.

Not really. Just a typo. Fixed.

That's about it!

I think that covers what's happened so far. We've got these issues fixed in house, and I think we're going to wait just a bit more time to make sure that nothing else serious is reported while we're feeling like we've got a handle on everything that's wrong.

Thanks for your patience and support, as always. One of these days we're going to release something and it'll be perfect, and then someone will send me a unicorn, and I'll ride off on a rainbow road to the land of chocolate and ice cream. I just know it.

Until then.

SUMMARY: Shirt Pocket announces the immediate availability of SuperDuper! 2.6 - improved and now compatible with Snow Leopard

Shirt Pocket is happy to announce that SuperDuper 2.6 is now available as a free update for all users. The new version includes full Snow Leopard support as well as many other new features, such as "Backup on connect", which, when configured, automatically backups up to a drive when it's connected to the Macintosh.

Of course, we didn't stop there. Version 2.6 improves over a hundred aspects of our 2005 and 2006 Macworld Eddy-award winning application, improving nearly every part of the program, from performance improvements and additional AppleScript capabilities to additional features like "Eject on successful completion" and support for the Sparse Bundle image type.

"SuperDuper! 2.6 isn't just a compatibility release for Snow Leopard" said David Nanian, owner of Shirt Pocket, talking to himself and feeling a bit Bob Doleish as he wrote the press release. "We've added many high-value features that our users are going to love, and it's an even better complement to Time Machine—all without any increase in complexity. With SuperDuper!, recovery from a disk crash is just a matter of rebooting from the backup!"

SuperDuper continues to support both Intel and Power PC Macs running Mac OS X 10.4 or later, including the latest 10.6 release, and is a free update for existing users. The unregistered version will perform full backups for free, and never expires. 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'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.)