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!