Hit me two times Wednesday, February 26, 2014

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.

Take a breath Saturday, February 22, 2014

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!

Page 1 of 1 pages