Well, that took longer than we though it would, mostly because we wanted to make sure we got very broad external testing coverage before release (extremely important when we make changes to the copy engine), but I'm happy to say that SuperDuper! v2.7.2 is now available.

To summarize the changes made:

• Full Mavericks support, including the return of auto-mount and auto-eject for scheduled copies.
• Scheduling has transitioned to launchd from cron
• New volume size information available in the source and destination pop-ups
• New volume information tooltips for the source and destination pop-up lists
• Warning in the "What's going to happen?" section of the UI when the source drive has significantly more data than the capacity of the destination
• Improvements to "Backup on connect" to help with a launchd bug in "WatchPaths"
• Works around a problem in Mavericks with Spotlight handling (where mdsutil can't talk to mds and returns IPC errors)
• Improvements around prebinding (only done when strictly necessary)
• Elimination of the rare "Copy Job" unclickable dialog
• Smart Update speed improvements
• Scheduled Copies window will re-open on launch if open on quit again on 10.8+
• Applescript launch no longer loads default settings on 10.8+
• Large EAs no longer return "result too large" errors
• Scheduled copies no longer generate annoying and incorrect "controlling your computer" security prompts
• Now requires OS X 10.6 or later (but 2.7.1 still available for those using 10.4 and 10.5)
• Various other optimizations, changes, and things I've forgotten because I am old and broken

Thanks for your patience as we've worked to get the release out, and enjoy the new and improved features!

I think it was around Leopard's release--which seems like forever ago--that we ended up being later than expected with an update to SuperDuper. Since we've missed our internal target for release of 2.7.2, I thought I'd write a quick blog post to fill you in on what's going on, and why we haven't released the update yet.

First off, the update we have in external beta right now has been working really well for quite a long time. We're basically getting no reports of failures, which is a good thing, since it confirms internal testing.

However, we noticed two things in 2.7.1 under Mavericks, being used by the broader population, that we needed to fix.

The (demonic) MDS Daemon

As some of you may know, Spotlight's indexing daemon is called "mds", and runs automatically. It's loaded by launchd, and does its thing transparently, at low priority. Most of the time you won't even notice it.

In the past, we've temporarily turned mds off with mdsutil during the SuperDuper copy to stop it from indexing the backup during creation.

Which was fine, until we were hit by that dog's big wave.

Under Mavericks, on a few systems, mds seems to be crashing (in some cases it's been unloaded, rather than using the Privacy tab of the Spotlight preference pane). When this happens, mdsutil now throws an error, indicating that it can't talk to the daemon, and we stop. Re-running will often work (since mds gets reloaded), but it's intermittent and annoying.

We're going to stop disabling mds in 2.7.2 to work around this problem. Remember, you can always disable Spotlight indexing of a backup with the Privacy tab in the Spotlight preference pane (as long as you're using Smart Update): something I'd generally recommend since it also prevents backup results from showing up in a Spotlight search.

Extended Attributes of Unusual Size

Way back in Tiger (as I recall, it's been a while), Apple added Extended Attribute support to HFS+. The pretty standard getxattr/setxattr/listxattr calls were supported, and we've been using them to copy the attributes ever since their introduction. Mostly, they used to be small.

These days, Extended Attributes can be quite large (compressed files are actually stored, in some cases, in the resource fork EA), so we've always tried to copy them 256K at a time (to avoid allocating gigantic amounts of memory--they can be up to 2GB in size). This seemed to be fully supported by the get/set APIs, and worked fine.

However, in Mavericks, we started getting ERANGE errors on some (again, very few) user systems.

It turns out that the failure happens when a non-ResourceFork EA turns out to be larger than our 256K buffer. These are super rare, but we've found a few users who had PDFs with kMDItemComments that were gigantic (on the order of 2MB) and some GIFs with corrupted kMDItemWhereFroms that were huge and contained image data.

After carefully reviewing the code along with the current version of the man page (a tip of the pocket to Rich Siegel for helping out with a code review), we've determined the cause of the problem, and it's definitely our bug.

Basically, the com.apple.ResourceFork EA, where large compressed file data is stored, supports chunked reads and writes. Surprisingly, other EAs do not (even though they can be just as large, as mentioned above), and thus must be copied in one go, even if they're as large as 2GB. We were trying to copy them 256K at a time, which failed as soon as we went to the 2nd chunk, and we'd never hit a large, non-ResourceFork EA until Mavericks' release.

This took much too long to figure out. But now that we've determined the cause of the problem, and have fixed it in a way that maintains efficiency (and doesn't unnecessarily bloat our memory footprint), we'll have one more beta build and get the result, assuming success, into your hands.

Thanks for your patience. While you wait, you can try to diagram the last, terrible sentence of the previous paragraph. Good luck!

So, it's been a while!

For the tl;dr crowd out there, SuperDuper! 2.7.1 backs up Mavericks just fine, so we've got you covered, day-and-date, with backups.

In addition, I'm happy to announce that we will, have an even better Mavericks-compatible release 2.7.2 available shortly.

For more patient readers, here's some hopefully interesting detail.

Despite few visible changes, we've done quite a bit behind the scenes to bring back the cool automatic volume mount/eject feature that stopped working in Mountain Lion because of some new "security features". (It should also eliminate that intermittent, weird, unclickable "Application isn't running" panels and the like that occasionally happened to a few users.)

But every OS release presents new challenges, and Mavericks is no exception.

As you may know, our scheduling feature runs a little application called "Copy Job" behind the scenes. Copy Job gets launched by the system, figures out what the scheduled copy should be, and then launches SuperDuper! to actually do the copying.

When Copy Job starts, one of the first thing it does is ask the OS whether SuperDuper! is already running. That way, it knows whether or not it should quit it at the end of a successful backup.

For some reason, in Mavericks, this check (and a second one that checks whether Growl is running) now generates a scary security warning that claims Copy Job is trying to strangle kittens or some such—and then doesn't give you an easy way to disable the warning (it's a multi-step, confusing process, as you'll see).

We've found a way around this prompt, but it requires that you delete and recreate your existing schedules once 2.7.2 is released. To be blunt, that sucks, I wish it wasn't necessary, and I'm truly sorry for the hassle.

On a slightly sad note, the new 2.7.2 version drops support for Tiger and Leopard (10.4 and 10.5). It's become too difficult to build and test new versions that are compatible with these years-old OS versions (hard to believe, I know, but Tiger came out in 2005, and Leopard in 2007).

2.7.1 will still be available, of course, and can still be used with those older OS versions.

The new 2.7.2 version is in the final stages of testing, and will be available for automatic upgrade shortly as a free update.

Thanks for reading, and thanks for using, trusting and recommending SuperDuper. We couldn't do this without you.

We've been pretty happy with the way v2.7's been behaving out there in the Big, Beautiful World, but as my previous posts indicated there were some bugs that we needed to deal with.

And deal we have: I'm happy to announce the v2.7.1, available today, has resolved the vast majority of them:

• We've fixed the "too many open files" error, and the "index out of bounds" exception. While we were doing that, we improved our error handling even more, and added additional, more specific diagnostic messages during a failure that will help you (and us) pinpoint the cause of disk errors when they occur.

• The statistics in the "status view" and in the log have been corrected. Previously, they were underreporting the number of files and bytes copied in some situations (even though the files were being copied as they should have been).

• 10.4.11 users had a minor problem with Growl notifications that has been dealt with, too.

A fix for automatic mounting under 10.8 is still in progress (it's not a simple fix, even though we know what to do).

That'll do it for now—we'll head back to the code mines to work the remaining seam while you surface dwellers enjoy.

Hope you had a great Labor Day weekend!

Two blog posts in two days - shocking!

The rollout of 2.7 is going well: this is probably the smoothest new version release we've had. But, of course, when you go from "small batch testing" to "large batch testing", you find some things that slipped through the cracks.

Here's what we've found and what we're working on - save for the first two, these are all extremely rare (fewer than ten users affected by all the issues combined), but I thought they might be interesting:

1. As mentioned in the previous blog post, automatic mounting of ejected local volumes doesn't work under Mountain Lion when time-triggered schedules run. A fix is still in process.

2. Some users on 10.5 and earlier are getting errors during the update process. If the update doesn't install automatically, you can download it from the Shirt Pocket web site and install manually.

3. We've had a few reports of a "too many open files" errors in the log. This seems to have to do with some copy-retry logic for busy files. Investigation continues: if you're encountering this (unlikely), quit all active applications and retry the copy.

4. Another three or four users are getting an exception with an "index out of bounds" error. We're pretty sure this is related to folders whose case has changed on a case-insensitive volume: we're trying to optimize for that, and update the case of (rename) the folder on the destination, and in some situations this can generate an error. To work around the problem, do an erase-then-copy backup rather than a Smart Update (one time).

5. Finally, there's some kind of issue with utilities that mount volumes outside of the /Volumes folder (again, a very rare case): we're trying to descend into that mount, which will often generate an error. If this is happening to you, you can ignore the mount point/folder with a copy script by following the steps in the User's Guide.

That's about it! We'll continue feeding Xcode some Zwiebacks to get these few teething problems taken care of and get another update out as soon as we're done.

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!

For SuperDuper! users, I'll cut quickly to the chase here: we should be releasing an update this weekend that resolves the few issues that inevitably arise when a new update comes out. Thanks for your patience as we worked through the issues, and thanks to the users who helped us by running special test versions to ensure we had the problems fixed.

This is a bit of a stressful time to be releasing an update, as I mentioned before: I'm in Italy, training for the Maratona dles Dolomites, which happens tomorrow.

My schedule has been kind of crazy, as everyone suddenly remembers they have to back up before a major OS release (and given the minor issues we've been dealing with): I get up around 5-6am, answer as much email as I can before 7:30am, join the group for breakfast and route review, pack (we were moving to different lodging every day before today), get on the bike, ride over mountain passes until evening, shower, answer email until 7:30pm, eat, and then work from 9-10pm until sometime after 1am.

And repeat.

Our total activity so far, pre-Maratona: 210 miles of cycling over about 18 hours and 31 minutes, with 26,813 feet of climbing. Tomorrow's event will add up to 85 more miles and 14,000 feet of climbing over a long day with thousands of other cyclists from all over the world, for a trip total of around 295 miles and more than 30,000 feet of up.

Now, for many people (and you know who you are) that's really not that much. But this is the first time I've done anything quite this strenuous, and combined with a full day of work it's been mentally and physically exhausting. But I knew what I was in for when I signed up: the riding's been well planned, guided and supported, and SuperDuper users have (for the most part) been pretty understanding, so thanks!

With that, on to more detailed information about the update. Assuming final confirmation tests go OK, it should come out today (Saturday). Full information about the update is in the release notes, but I wanted to highlight a few items here.

First, we've fixed the problem with Tiger (10.4) where most AppleScript-based actions didn't work, including scheduling and post-copy actions like Shutdown and Restart. As soon as we determined this was a problem, we turned off auto-updating for 10.4 users.

This problem was due to a misconfigured build script that compiled our dictionary for 10.5 and later rather than 10.4 and later.

It's getting harder and harder for us to maintain compatibility with Tiger, and doing so is preventing us from using the new APIs introduced in Leopard, so I expect that we'll continue with our policy of supporting two OS versions back with new releases of SD! when Lion comes out. We'll still provide support for Tiger users, of course, but new versions will not be compatible as we move forward.

Many Leopard users found that the v2.6.3 was generating errors with their system log, asl logs or some other 'active' files. As above, as soon as we received a few similar reports of this problem, we turned off auto-updating for 10.5 users until we could run down the problem.

It turned out that some new, more aggressive post-copy error checking was a bit too aggressive on 10.5, and when users had very active system logging (due to various system errors that were getting written multiple times a second), a failure to verify file size (etc) information post-copy caused us to raise an I/O error for the file.

We've loosened up our check a bit here to avoid this problem, while still doing additional verification to catch more problems under all OS versions.

So there you go: auto-update will be turned back on for 10.4 and later sometime today, and you'll be able to enjoy improved operation while I enjoy a rest day off the bike.

As always, thanks for your emails, support requests, registrations and comments!

There's a certain way I like to release a version of SuperDuper, or any application, really. It goes something like this:

1. We plan a healthy mix of fixes, tweaks and features.
2. Those new features are designed and implemented.
3. Once we've put them through a bunch of internal testing, we recruit a mix of old and new testers to put things through the "customer wringer".
4. The fix/test cycle is repeated as many times as is necessary to ensure that we're meeting our quality standards, that new features are working as desired and satisfying the needs we'd identified during their design, etc.
5. During the last few testing cycles, I usually start telling the story of the release (which, at that point, we're pretty sure we're nearly done with), highlighting some of the more interesting elements.
6. Finally, we freeze the release and, with any luck, we release shortly after the release candidate is OK'ed by internal and external tests.

And I highlight all this because the whole "telling stories" part of our next release is going to be much shorter than usual, and we'll be doing other things a bit differently as well.

Ring One–Personal

As anyone who follows me on Twitter is aware, I've been doing a lot of cycling over the past few years (and tweeting about it in a rather boring way, sorry). After a cycling trip to Italy last fall, and based on a suggestion by one of the guides, I decided to train for (and participate in) the Maratona dles Dolomites.

So, for the last six months or so—in sun, snow and rain—I've been riding and training (well, trying to train) for this huge, 9500-participant Grand Fondo. In one day, we'll be riding about 85 miles and over 7 big passes, with 14,000 feet of climbing. It's the first time I've ever tried anything this...crazy. Ready or not (mostly not), on July 2nd, I'm headed to Italy for the race, which happens on the 10th.

Those ten hard-date days were running through my head when the 2011 WWDC keynote was broadcast earlier this year.

Ring Two—Professional

As the various rumor sites could tell you, it's always hard to know when Apple is going to do things. But given that WWDC was likely going to be all about 10.7, and last year's WWDC was about iOS, it seemed a reasonably safe bet that the release of 10.7 would be well after this year's WWDC.

Well that was a bad bet.

Apple announced that Lion will be coming out "in July". In other words, the release window opens tomorrow (I'm posting this on June 30th). Given the current state of things, our current 2.6.2 release of SuperDuper is not Lion compatible. Specifically, we know we have two issues of significance under Lion:

• Deprecated command-line tool The "disktool" command was deprecated and effectively removed, and we rely on that for a number of things, including refreshing disk mounts when a copy starts, and automounting during a scheduled copy.
• Updater crashes Our automatic updater crashes under Lion, which makes it hard for Lion users to update (although they can download from our site and install manually).

With that in mind, also remember that Apple is going to be releasing this through the App Store. That means that there's no delay between an "RTM" build (which we can test against) and when you get the GM: it'll get declared RTM, someone will push a button somewhere and BAM! it's GM, and in the App Store.

Add to that the fact that I'll be gone nearly half of July. Which means, if Lion comes out in the first half of the month, as it very well could, and probably will...I think you can see where this is going.

Ring Three–Where the Rubber Meets the Road

Well, perhaps not where you think. We're not going to be late with Lion compatibility, unless something really crazy unusual happens between now and when Lion hits your Mac.

What it does mean is that some of the more interesting things we were going to put in this update will be postponed until later, and we're going to have to put this out with "initial" Lion compatibility, as much as I hate doing that.

So here's the plan: we're going to release version 2.6.3 of SuperDuper! in the next few days (probably on July 1st). This version has a lot of small things in it, some of which will significantly improve the user experience. Examples include:

• Initial Lion compatibility As I've explained, Lion is not out, so we can't promise that we'll be compatible with it when it is released. But SuperDuper 2.6.3 works well with the test version of Lion that we have now, and should work fine when the Big Button is pressed.
• Better scheduling A small change that should help a lot of users. Right now, it's too easy for a user to accidentally create multiple schedules. In the new version, the "Schedule..." button brings up an existing schedule for the source/destination drive pair if there is one (which is what most users expect it to do). Users can still create another schedule for the same pair of drives by Option+clicking Schedule. (I could write an entire post about this one change, and hopefully will be able to in the future, since it's one of the major errors I made in SD!'s quickly-reworked-after-the-original-disaster schedule design.)
• Improved volume failure detection If the destination volume vanishes during the copy, we detect the failure and stop the copy more reliably than before. This should avoid cases where the destination drive's mount point converts to a folder and files are copied to a "hidden" location (/Volumes) on the startup volume.
• Antivirus compatibility improvements We've tried to work around some incompatibilities with NAV that would cause intermittent issues for users that had that installed.
• Better support submission We've had an integrated email support submitter for a long time, but it relied on the NSMessaging framework, which has been deprecated. So, we've moved to a "direct submit" model. You shouldn't see any differences locally, but it'll work in more situations, regardless of your email client. (The downside is that we can't 'automatically reply' to one of these messages, which means a lot more work for me...)
• Expanded automount/ejection We now allow internal drives to be ejected, so they can participate in automatic mounting when scheduling, and can be selected as an ejectable volume after a copy.
• Various other improvements, fixes and tweaks We've touched pretty much every area of SuperDuper! in some subtle (and some not so subtle) ways, with more to come.

Thanks for Coming—Visit the Midway!

So there you go: we'll soon have SuperDuper! v2.6.3 available. You should endeavor to upgrade to the new release before you upgrade to Lion.

I hope you like the new release! If you're interested, follow me on Twitter where I'll be posting about the Grand Fondo a bit, and will be posting updates about SuperDuper! as necessary.

Support during these two weeks will be a bit slower than usual, because I'll be riding during the day, and only able to post at night. Apologies in advance if support feels less "spectacularly fast" during these two weeks: I'll do my best to respond as quickly as I can.

Thanks, as always, for using SuperDuper: we couldn't do any of this without you, and we'll continue to do our best to make SuperDuper an application worthy of your praise and personal recommendations.

The What

Ever been confronted by a Spinning Pinwheel of Death on launch of SuperDuper! on Snow Leopard and, while waiting for it to stop doing that, raised your hands to the sky and cursed me and the ground I walk on?

Hey, me too (without the self-cursing—kids, remember, if you curse yourself you'll grow hair on your soul)! But (and here's the important part) it's not unique to SuperDuper!. You'll also see this when you do a File > Open, File > Save As, and many other actions. It's not just a delay due to drive spin-up, and there's a fix!

The Why

I can't pretend to totally understand why this happens, so please don't ask, but it seems that the dyld cache (if you don't know what that is, read it as "stuff deep inside OS X") gets in some sort of weird state, and that state is often seen, up in userland, as these annoying, inexplicable SPOD delays.

Might be best to think "damnable munchkins" is the real reason why. Or circuit ants. Or blame the iPhone 4's antenna: it's Mark Papermaster: he's taking the blame for everything else and, at this point, probably wouldn't mind.

The First Fix (for Users Uncomfortable with Terminal)

The easiest way to fix this is to power off your Mac, hold down the Shift key, keep it down and power back on. Keep Shift down all the way to the desktop. This starts your Mac, more slowly, in Safe Boot, which automatically rebuilds this cache (among other things).

When you're totally logged in and running, try running SuperDuper! or your other app that was slow with File > Open. You'll note that it's quite fast.

Now, restart your Mac normally. And—check that out—it's still fast! Yay!

The Second Fix (for the Terminal Savvy User, or the Bold and Brave)

If you're comfortable with Terminal, you can do this without the Safe Boot restart:

1. Open Terminal.

2. Copy the following to the clipboard:

   sudo update_dyld_shared_cache -force

3. Paste that into Terminal.

4. Press Return at the end.
5. When prompted, enter your password (it'll be invisible) and press Return.
6. When it's completed and the prompt returns, quit Terminal and restart your Mac.

Poof! Problem solved.

In Sum

Hopefully this worked for you, and was useful. Enjoy your faster Mac, and stop cursing me!

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.