Public betas mean more storytelling on the blog. I feel a bit like we're developing in public—something I don't really like doing—but I hope it's interesting to those of you reading the blog and testing both El Capitan and these public SuperDuper releases.

One at a time, please

Ever since Ye Olden Days of OS X, there's been a handy Unix command called "lockfile"—in /usr/bin—that creates semaphores. It's quite handy in scripts of various sorts to ensure that "critical" sections are only executed by one script at a time, if more than one instance of that script might be running simultaneously. Scripts could be anything with shell access: shell scripts, perl scripts, AppleScripts...whatever.

We've used this for a long time in SuperDuper's schedule driver (which has always been written in AppleScript as an example of how to use SuperDuper!'s handy scripting interface); since you could have any number of schedules running at any given time, there are some operations that need to be atomic, and lockfile facilitated that. Basically, all the instances of the schedule scripts coöperate (you're welcome, New Yorker style guide, I hope your writers no longer feel so alone) using a semaphore that ensures only one runs at a time.

And all was great in the world.

Meep meep

Little did we know that there was a shoe—or an ACME-branded anvil—preparing to drop (although perhaps the fact that it was in /usr/bin was a hint): in El Capitan B4, Apple decided to stop shipping Procmail, and with it, lockfile. It wasn't deprecated and then removed... it was unceremoniously sent to the bit bucket. So, as of B4, scheduling in El Capitan broke.

There isn't any equivalent command in OS X that we could find, but there were a number of methods we could have used to fix this:

• Use a complicated shell script, along with the seemingly-atomic mkdir command, to create and manage our own semaphore, using similar semantics
• Add a command to our AppleScript dictionary to implement a semaphore
• Add some commands to another utility program we have to implement semaphores
• Create our own separate lockfile-equivalent utility
• Engage in a futile effort to get lockfile put back into OS X (not going to happen, of course, since the change was obviously intentional; indeed, our bug was closed "as intended")
• Crawl into a dark room and cry softly, hoping the problem resolves itself

There's no crying in OS X, mostly

In the end, we did none of those things. Instead, since Procmail is Open Source, we changed our build process to build lockfile as well, and included that command, unmodified, in our bundle.

Et Voilà!

This also meant we had to change the scripts that were looking for lockfile to find our application bundle and call the new, "local" version of lockfile instead. And that means, unfortunately, that users have to delete and recreate their schedules.

I hate it when that's necessary. Really. Not just because it means lots of additional tech support (people don't usually read the release notes). I hate it because it's a pain, even though it's not hard, and it means an update isn't as transparent as I want it to be. New versions of SuperDuper! should drop in, require no work, and present no surprises to the user, other than pleasant ones. Unfortunately, sometimes reality gets in the way.

The great reward

So without further ado, download Beta 3 - and don't forget to delete and recreate your schedules!

If it's not one thing, it's nothing, at least this time.

We'd developed the current Beta of SuperDuper using the most current Developer Beta versions, based on the feedback of various testers (and, of course, our own testing).

As I mentioned in my last blog post, we'd researched the problem we had copying El Capitan, and we came up with a way of getting the drive copied, although System Protection was disabled on the copy until the OS was reinstalled.

We thought it was critical to release that as soon as the Public Beta was announced, to ensure that the larger pool of public testers had access to it - we didn't want that audience to go without the ability to back up. And it's been working great.

Turns out...

Apple fixed the problem with copying the "com.apple.rootless" attribute in the Public Beta! So, with the release of our Beta 2 (download below), we've included the ability to copy with that EA preserved, and thus system protection is maintained on the copy as well. Plus, there's no need to erase when restoring.

This is all great news for users: basically, copying will work as it always has.

You can download the improved/de-improved Beta 2 here. Enjoy!

Every new OS X release has its own special challenges, and OS X 10.11 - which I still have trouble referring to as "El Capitan" - is no different. And in our testing (which we commenced immediately upon availability of the developer preview), we found that we couldn't make a copy of an El Capitan disk due to the new system protection or rootless feature.

Rootless mode is a good thing, for the most part. It makes OS X more secure by protecting various system folders, ensuring that even applications that obtain escalated privileges through trickery (or hacking) can't mess with these critical locations. (It also means that jailbreaking iOS 9 is likely to be much more difficult, for those who care about that kind of thing.)

In our investigation, we've found that a new Extended Attribute -- com.apple.rootless -- is used to mark files and folders with this new protection. No process other than certain Apple-signed-and-authored ones can remove or write this attribute, and files and folders marked with this attribute cannot be changed. However, those files and folders can be read and copied.

This means that, for those using El Capitan, we can't hint obliquely that we're compatible, as we have in the past, where our current version worked even though we couldn't declare that compatibility until the final build. This time, the current version of SuperDuper is dead in the water on El Capitan. It just won't work.

But don't dismay: we've worked to change that. I'm happy to say, to those of you who are on the Beta (and those who are going to join the public beta today), we've developed and tested a Beta version of SuperDuper that makes bootable copies of El Capitan. There's a link to download it at the end of this post.

But please don't skip down there. Keep reading.

There are a few minor caveats, and some things to keep in mind.

First, and most importantly, OS X 10.11 is in Beta, and so is this build of SuperDuper. While we've been super careful about changing as little as possible, El Capitan is a big update, and there may be things that don't work. There may be things that don't work as well as you'd like. If that's the case, report the problem to the appropriate party. We're happy to get the feedback, and I'm sure Apple is as well.

Operationally, there are some known, minor issues. The most inconsequential one is that Repair Permissions is no longer available under El Capitan, so we disable it in Options. I can't say it will be missed.

Since we can't write the com.apple.rootless EA, SuperDuper removes it during the copy. That means the backup -- while fully functional and bootable -- is not an "exact copy" of the source. Specifically, SuperDuper! must disable the system protection feature on the backup, and cannot recreate it when you restore.

That's a relatively minor difference, but it's an important one. After restore, your system becomes vulnerable to the kinds of attacks that Apple is specifically protecting against.

It's easy to regain full system protection features: you simply need to reinstall the OS from the App Store. You can do this at your leisure, but doing it as soon as possible means you're less vulnerable (even though that vulnerability is quite small). It's a painless process, and it writes the fresh OS under your existing applications and data. As an added benefit, it will speed up your boot process, since it'll recreate certain caches that non-special-Apple-programs can no longer update.

Also, for this version, if you want to restore over an existing El Capitan install, and there are changes in protected system folders, you cannot use Smart Update (because we can't overwrite those protected files, or write to those protected folders). We're hoping to remove this restriction in the next release.

That's it for now! Thanks, as always, for using and recommending SuperDuper: we appreciate it, and couldn't do it without your support.

Download away!

Those of you who follow me on Twitter (I'm @dnanian) may have read that we were slightly surprised by Yosemite's release, which came out a week earlier than we expected. Fortunately, we were ready with a compatible, tested version—but it wasn't as optimized as we wanted it to be.

Basically, we knew we had reliable and safe copies of Yosemite, but there were cases where our change detection was too conservative, and thus we were copying too much.

In some cases (for users of the f-secure antivirus program, for example), we'd end up copying some files every time they ran, even when Smart Update was used, due to f-secure's crazy use of Extended Attributes to mark files as "clean".

We also found a case where some of the data in the file was being compared when it didn't need to be. This was, of course, "safe", but it was also sub-optimal (and obviously wrong).

I'm happy to say that we've spent much of the last month completing the additional work we wanted to finish, as well as polishing and improving 2.7.3 based on the feedback we've received from users.

Not only have we fixed the cases where extra or unnecessary copying was done, we've made significant improvements across the board: copying is faster than ever; some longstanding (though minor) UI issues were fixed; we've even radically reworked the way we ask the system for the list of attached volumes, which should eliminate the delay some users experienced when launching and completing copies.

We've even fixed the animation bug that caused the update notice to not fully display for some users. Unfortunately, since the code that displays the update is in the "current" version, not the "new" version, some of you are going to see the problem again with this update (and I'll be getting thousands of emails about it). Future update notices should display correctly (except in one case, hence the Bullwinkle reference in the release notes)!

Finally, we've added specific support for Backblaze's ".bzvol" folder, which is now not copied during regular backups (as recommended by Backblaze), and any existing .bzvol folders on a destination are preserved during Smart Update.

All in all, I think you're going to really like v2.7.4.

As always, thanks for using, recommending (and hopefully registering) SuperDuper!

Ever since the feature was introduced, we've had a small number of users report that Backup on Connect suddenly, with no "inciting event", stops working for them. I was never able to reproduce the problem, but had a way to get functionality back: basically, reinstalling. Which sucks, and I hated having to suggest it. But we do what we have to do.

For years I've been at a loss to figure out why, but thanks to Frank Fackelmayer, who was willing to let me provide him with a bunch of debugging versions, I've managed to get a handle on the bug, and have fixed it.

I can't tell you how awesome it is to fix a longstanding, rare, confusing, crazy-seeming bug. But this isn't going to be one of those amazing stories of heroism in the face of threading deadlock. No, it's going to show how stupid I can be. Or, at the very least, how stupid I feel now that I know what the problem is.

Now that we're all in agreement that I'm about to be proven an idiot (foreshadowing?), let's begin!

How it's done

Backup on Connect is implemented as an AppleScript that is called by launchd. We register our agent for two events: volume mount and -- since there's no "volume unmount" event -- a WatchPaths on the Volumes folder.

When we get one of these, the script determines what drives have mounted or unmounted, and for each "new" volume, it checks the Scheduled Copies folder for files that match the drive name. In that list, it checks each one to see if the target volume in the settings data is the same as the mounted volume name. If so, the script is launched.

All well and good - relatively simple stuff, and the kind of thing that AppleScript is pretty darn good at (it's so easy to ask it for, say, a collection of files containing the word "idiot", "stupid" or "dummy").

How it's done wrong

But here things went wrong. When the script retrieves the list of matching schedule bundles (bzzt) from Finder, I simply asked for any files that contained the volume name. I knew it might overmatch (returning files with source volumes with the same name, for example), but I handled that case, since the overmatch would get double-checked when verifying the target volume name.

All good! I am a super genius! Ship it!

Perhaps you see where this is going.

This particular "super genius" didn't consider that there might be a file in that folder that matched but wasn't a scheduling settings package. Or a match that wouldn't have a settings file in it to check. And that "super genius" didn't handle the potential error from the settings file parse. Because: "super genius"--which you may now read as "idiot".

Worse still, every SuperDuper installation had one file (in pre-2.7.2) and now two files (in 2.7.2) that match if the drive is named "Backup": "Backup by time.scpt" and "Backup on mount.scpt".

I will leave determining what the most common name for a Backup volume is as an exercise for the reader. It's a real puzzler, so don't hurt yourself.

Random is not your friend

So, why didn't this happen to everyone? And why couldn't I ever reproduce it?

Basically, the order the files were returned from Finder determined whether the script would work or not. In my tests, they always came in last, so no problem. But if they came in somewhere before the appropriate .sdsp...boom. So, basically, it was a bit random.

The solution is almost always easy when the problem is known, once the head-slamming-on-desk impact injury has healed enough for clear thought to return.

Homework

I've made a pre-release version of the fix (which I've tested) available here.

To install, download to your Mac. Once you have the file, open the SuperDuper! application bundle (Control+click, Show Package Contents), navigate to Contents/Resources in there, and replace the "Backup on Mount.scpt" with the one you downloaded. Also, replace the same file in Library/Application Support/SuperDuper!/Scheduled Copies.

So, if you're interested, give it a try and let me know if you have trouble. If you don't want to do this yourself, the fix will, of course, be included in the next update.

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.