News on the March! Wednesday, September 13, 2017

It's inevitable—another year, another macOS version (I am still not used to typing "macOS"), and another build up to a significant SuperDuper! release. Sorry I haven't been blogging the whole way through, but it's been busy, and I just haven't had the time.

As of this morning, we have a release date - September 25th. So, for those asking (and there are a lot of you), let's talk about High Sierra. Lucky 13! Woo!

APFS

First, we'll definitely be supporting APFS. That work has been in progress for some time, and continues as of this post. We already have copying to and from APFS volumes working "in the lab", as it were, and testing is ongoing.

The bad news is I'm not confident enough to say we're going to release our APFS support day-and-date.

I know this kind of hedging is disappointing. But it's important to note that Apple still hasn't released any documentation on the "proper" way to create a bootable APFS volume. An example of what they have in mind was released for the very first time when the High Sierra developer release came out a few months ago, but that's it. We basically have to make an educated guess about what they want.

We've designed and implemented that, and it's significantly different than HFS+'s boot setup, with various special partitions dedicated to specific purposes (even a separate VM volume!), and entire new volume management system, etc.

So, we have both copying and boot working, and we're testing it carefully to try to cover all of the various permutations that can occur. Because no guidance or documentation is available, and the process is all reverse-engineered from existing volumes, it's difficult to know what might happen in the future...and protecting against mistakes, and informing users what their potential actions mean, is really critical.

For example, what happens if you do an "Erase, then copy" from an HFS+ volume to an APFS volume? In our current version, we match the format of the source when we erase. But, HFS+ can't be in an APFS container. So, we'd have to convert the container to a regular GUID partition. And since there might be other APFS volumes in that container, you'd end up destroying them.

Not good. And that's just one case.

So, we're being cautious, knowing that users who have continually followed our advice (namely more backups are always better than fewer, and use more than one backup program, such as SuperDuper! and Time Machine rather than either on its own) will still be covered by Time Machine if they jump the High Sierra update as soon as it becomes available.

But what about HFS+?

Yes, making a backup from APFS to HFS+, and booting off that, can work as it always has (once our APFS support is released). And HFS+ to HFS+ works as expected as well, save for a few small issues in 2.9.1.

In particular, Apple has further tightened its System Integrity Protection process, and is completely denying access to some files on the startup volume, even when copying to a non-startup volume. We consider those errors ("Operation not permitted") to be fatal in 2.9.1, and so we stop. We have a simple, preference-based workaround for this that we've provided to people during the beta on request, and 2.9.2 has it built-in. (This is the kind of thing I'm talking about when I said "it's difficult to know what might happen"--we didn't know what could happen with SIP, and so we planned for possible changes.)

But since APFS is, again, basically undocumented... what could that backup be missing? How will changes like filename normalization affect future copies if a dot-update modifies behavior? How do you make a snapshot, since that is obviously intended to be a better source for a backup? And do androids actually dream of electric sheep?

These are the kinds of things that have been keeping us awake at night at Shirt Pocket HQ. I feel like I've aged as much as a two-term President.

Anyway, we're grinding through this all as quickly as we can. We don't want to finish until we're sure we have the shipping bits, because, unlike with earlier OS versions, we're dealing with an entire new file system. We'd rather be late than wrong.

We're probably not wrong, but we want to be sure.

Automatic conversion

Speaking of being sure, one of the scariest part of High Sierra is the fact that, if you have an SSD, you'll have no choice: you're going to be converted to APFS, whether you like it or not. Apple is obviously confident about this process, or they wouldn't do it, but even if the conversion is successful, it's important to note that while that means it worked from their point of view -- conversion accomplished! -- this changeover won't be without pain.

  1. Your existing, valuable low-level tools, such as Disk Warrior, will instantly be rendered useless. In a pinch where Disk Utility can't fix it? Tough luck.

  2. Want to host an HFS+ volume on your drive? You can't in an APFS container.

  3. APFS doesn't seem to be faster than HFS+ (which is not to say it won't ever be, or that it won't be more stable...a low bar, I know). That cool demo where copying a whole directory is instantaneous? That's because the data isn't really being copied. It's being referenced, which is, of course, fast. Copying happens when you modify, so it's basically being done "lazily".

    But think about it. That also means that if you made a copy of your data "just in case", and you developed a bad spot on the drive, all copies of the file are now damaged, because they share the same data. Disk damage can now cascade across far more files than before, because you can't tell what's shared. Even snapshots can't save you if they're referencing the same bucket of damaged bits.

  4. So many other things.

There are going to be growing pains here, and a lot of it will be for long time developers who have been doing invaluable work for years, and unlike us, they have to start again from scratch. Need I say they deserve your support and encouragement?

64-bit

I'm also getting a lot of mail about our 64-bit plans, since there's been a pile of confusion coming out of the WWDC announcements, so let me try to set things straight.

High Sierra works fine with 32-bit apps. Come January, the App Store will stop accepting 32-bit store apps. And, at some point in the future, Apple will stop supporting 32-bit apps.

Now, for most apps, there's really no advantage to being 64-bit (save for some really minor system-wide memory benefits, which—frankly—were the other way around when 64-bit APIs were introduced, and no one complained about that). So for many developers this will be a lot of unnecessary work, with no end-user benefits.

All that said, while there's no rush to do so (they're not phasing out 32-bit for a while), our full High Sierra release will be 64-bit, so you can rest easy, knowing that we'll be ready for the actual phase-out well before it happens.

Should I Update to High Sierra?

I think I usually tell people to "take it slow" with an entirely new OS version. While there have been "huge win" updates in the past (10.6 is a great example), High Sierra isn't one of those.

Rather, while it may be a good (or even great) update over time, it also has the potential to destabilize things far more than anything that's come before. It's going to be hard to judge its impact until its wide release, and even then, it'll be a while.

If you're a normal user, I would strongly encourage you to not update to High Sierra right away. Let others take the risk. Wait until things calm down and the initial problems, which are inevitable, are fixed. Continue doing what you've been doing before High Sierra: you're not missing anything of significance.

Apple's going to be OK if their "adoption graph" doesn't go straight up in the air.

After all, why should you be a statistic when you have work to do?

But I Want to Update Right Away

Don't.

I Insist on Updating Immediately!

Sigh. OK. But don't say you haven't been warned: we don't all float down here.

Before you update, use SuperDuper to make a full backup or two. Check your backup by starting up from it. Then, unplug the backup drive from your Mac and put it somewhere safe.

As I've recommended elsewhere, you should be making multiple backups with other programs as well, including Time machine. So, after you update, continue to use Time Machine to back up. Given it's basically written by the same team as APFS, and Apple knows what is and isn't possible, even when they don't document it externally, this is your best bet to start with.

If you need to roll back to your previous OS, you cannot just use Smart Update. In fact, you also can't use Erase, then copy, because your internal drive has been converted to a storage scheme that won't work with anything earlier than High Sierra.

Surprise!

So, after starting up from your SuperDuper backup, use Disk Utility to erase the drive you want to restore to, by selecting the drive hardware above the volume, not the volume itself. That will roll you back to something that can properly host HFS+ and boot pre-High Sierra releases. You can then restore your SuperDuper! backup normally, using "Restore - all files" and "Erase, then copy" or "Smart Update".

But How Do I Back Up?

For the moment, as I said above, use Time Machine. Apple's teams know the details of APFS, and as such Time Machine isn't in the "limbo" we're in with regard to ensuring things are as they should be. Remember, disk space is cheap, and I know I say this too much, but it's true: no one was ever sad they had too many backups.

If you are running High Sierra with HFS+ (namely, if you have a spinning disk or Fusion drive), our just-released SuperDuper update will work fine. Use that in addition to Time Machine.

Our full, APFS-supporting version (with some other surprises) will be out as soon as we can get it finished. And we'll have a public beta when we're confident enough to put it in your hands.

This is Going to Cost Me a Ton, Isn't It.

Actually, no. Since 2004, we've never charged for SuperDuper updates, and our High Sierra update will be free of charge as well.

Clearly, we were dropped on the head as babies.

FIN

So there you go. I'll be back relatively soon with more.

SuperDuper! v2.9 - anti-AntiVirus (+ macOS Sierra) Wednesday, August 31, 2016

Hi, everyone!

I'm happy to say that we're releasing SuperDuper! v2.9 today, at long last. In fact, if you're reading this, it's out. Hooray!

This new release has a large number of enhancements and bug fixes that improve SuperDuper!'s responsiveness and performance. Many of these are longstanding items that required a significant amount of investigation, across many different systems, to diagnose and fix, so we're really grateful to the users who reported the problems and were willing to work with us to run down the underlying issues.

But rather than talk in detail about each (you can get the list of changes in Help > Release Notes), I want to discuss how SuperDuper! interacts with the bane of every copying application: Antivirus programs.

Anti-antivirus

Antivirus programs are getting more popular on the Mac, even while the threat environment doesn't get worse. And they're extending their reach, protecting against things like "phishing" emails. Plus, all Antivirus vendors include non-Mac threat signatures (mainly Windows applications) in with their Mac-specific applications, which tend to flag things that aren't really relevant.

The result of all this (beyond slowing copies down) is that Antivirus users are being informed of potential threats constantly, and before v2.9, each of these pseudo-threats would cause SuperDuper! to stop, because they're flagged as errors (specifically, "Permission Denied" errors) when we try to open the file for copying.

The vast majority of these files are in Junk mail folders. Due to the way Apple Mail (and similar applications) work, those files are cached locally. So, even though the user isn't really interacting with the mail, the files are on disk and copied, and that causes errors to happen much too often.

Given that error isn't Antivirus-specific, we've been reluctant to ignore them: our philosophy has always been to stop on errors (see the "I/O Error Handling" post) But, as more users install the apps, we've decided that the frequency of non-Antivirus related "Permission Denied" errors is so low (I haven't seen one in more than two years), the risk of ignoring these particular errors is minimal.

So, we've added a new preference -- which defaults to ON -- that ignores "Permission Denied" errors. We do log any occurrences, but we don't fail the copy.

This should significantly improve the lives of less technical users (or even technical ones who have Antivirus program use mandated by company policy).

macOS 10.12 - Sierra

To answer the inevitable question, we've been testing v2.9 on current Sierra builds, of course, and initial compatibility is looking good. Remember, though, Sierra is in beta. We do not have the final version to test against, anything can happen between now and Sierra's release, and as such we can't guarantee that we'll be fully compatible with the official, release version of macOS 10.12 until that happens.

Along similar lines, we're not (yet) APFS compatible. The documentation for APFS is still quite sparse, and given that it's in very early preview, we decided it was unwise to release an initially compatible version until it's a bit better documented and closer to done. (It's much easier for us to be pretty confident about the stability of the 8th beta of Sierra than these early releases of APFS.)

In the meantime, though, enjoy the new version, and don't hesitate to contact us if you have problems.

The Traditional Post-Release Debrief Monday, November 02, 2015

November has rolled around, and that means it's been a month or so since SuperDuper! was released for El Capitan. Rather than go through a litany of how awesome we are (I hope that's obvious), I thought I'd take a moment to discuss the things we've screwed up, bugs we've found, and other embarrassments. Prepare to judge us...harshly!

Update, schmupdate

First, as anticipated in previous blog posts, the broken automatic update (with an error at the end of the process, triggered by a last-minute change in System Integrity Protection, causing the update to fail) has been a never-ending series of hassles for our users (and a pretty unbelievable number of support requests).

Despite releasing the new version well before El Capitan came out, it's clear that people didn't update until they actually installed 10.11, and at that point the update failed.

Much of this is our fault. The update itself isn't displayed until the application launches, and a scheduled copy continues past the notice and completes the tasks at hand, then quits. That means that most users never even see SuperDuper! doing its thing, and thus never even know the update is available. So, by trying to be as "magic" and "unobtrusive" as possible, we end up hiding important information.

In most cases, this doesn't matter, since an update that is put out to work around a problem will be presented when a failure occurs. But in this case, it caused unnecessary stress, not to mention painful RSI flareups. (Not really, but man, I've been typing a lot on the new Magical Mystery Keyboard.)

Anyway, in the next major update we're definitely going to rework how this stuff happens. ("It's about time" shout the displeased and annoyed masses.)

Schedule screwup

This one's totally on me. I documented the problem with Apple's removal of /usr/bin/lockfile in this blog, but I forgot to add the fact that you have to delete and recreate your schedules to the update notice and release notes.

Not everyone on the 'net reads this blog. Who knew? (Me. Duh.)

Documenting Apple's Changes

El Capitan removed the ability for 3rd party applications to do certain things, and while we handle those cases well, I didn't actually document the changes in the release notes: 1. Repair Permissions is no longer an option (Apple removed it completely at the user/app level; it's been less than useful for many years now, so—as I indicated below—no big loss). 1. Non-Apple applications can no longer programmatically set the startup drive, so we can't offer that as an "On successful completion" option. 1. And, due to the above, the option to restart from the backup drive has also been disabled.

Save for some users' old habit of reflexively repairing permissions (we've always shipped with that option OFF), these are all used relatively rarely, so their loss is not keenly felt. Still, should have been in the release notes.

The Curious Case of the Tiny Pipe

Here's where I get a bit technical, so feel free to skip this section if you don't want the boring-ish details.

SuperDuper! is broken into a number of primary processes: a UI, an escalated privilege Agent, and the Copy Engine. (There are others, like the various parts of the scheduler, but those are the primary ones.)

Those processes communicate through Unix Pipes: basically, streams that run between two processes and allow commands to be issued and results returned. One process writes a task to the command pipe connected to the process it wants to control, and then reads the result from the result pipe.

This is how we've done things since the very first version of SuperDuper (and was, at the time, the Apple-sanctioned way of doing this kind of thing).

Works great, very Unix.

Weirdly, in El Capitan, we had a few users report that some commands—commands that are entirely static in our application, and issued to the shell—returned syntax errors. It didn't happen often, and we never saw it here, but when it did, the only thing that resolved the issue was restarting the Mac.

That's an annoying kind of problem, as you might guess.

We put together an instrumented series of builds for a user who was kind enough to run them (over and over and over), and determined that:

  1. When in this state, the pipe was only passing through 512 bytes of the write. Powers of two: always suspicious.
  2. No errors were returned from any of the write commands.
  3. No exceptions were thrown.
  4. The pipe wasn't buffered (or, we couldn't switch it to unbuffered if it was).
  5. Attempts to try to flush the pipe didn't work.
  6. Adding CRs (in case the pipe was somehow line-buffered) didn't do anything
  7. You get the idea. (Again, thanks to the kind soul who ran this stuff over and over as we tried things out.)

So, we had a pipe with a weird size, that wasn't returning errors, but also wasn't passing through the data we were writing to it, once it was over 512 bytes.

Reviewing the POSIX documentation on pipes, they're usually pretty big (as in 64K), but the guaranteed size is only 512 bytes.

A number that might be spookily familiar. (Yes, I wrote this post on Halloween. Why do you ask?)

It seems that, on some systems, the size of a pipe write can shrink much smaller than in previous versions of the OS, perhaps because of resource constraints (although our test system that was always failing was a new Mac Pro with tons of resources)...as small, as far as we can tell, as the guaranteed minimum of 512 bytes. So, when our commands got larger than that, things started to fail on some systems, sometimes.

Still quite annoying. And even with that, we'd expect an error to be returned or thrown when writing to the pipe, but that didn't happen...and seems to be a new bug in El Capitan. Very hard to report, because we don't have a reproduction case: we've never seen it happen in house, on any system. But at least we had a way to work around the problem.

We now chunk our writes to whatever dynamic minimum we find we need. In testing, that allowed the data to pass through the pipe even when smaller than normal, and the syntax error (caused by the truncated data) went away.

Problem, hopefully, solved!

Not that bad

As new-release problems go, those are all annoying, but not too bad. Of course, we hate having any issues at all, but better minor than major! Please take that into consideration as you go into deliberations.

And the new release with better release notes and the pipe fix? A beta version is now available to you here!

Enjoy and, as always, thanks for being a SuperDuper! user.

Oh Capitan, My Capitan! Sunday, September 13, 2015

It's not often that we get "official" final bits before Apple pushes the big red button that releases them to the public. I can't tell you how nice it is to be able to do the testing we need to do here before the email starts coming in, wondering when we're going to support the latest-and-greatest.

Well, sure, I guess I can tell you. It's nice. Really nice. Really, really nice. Thank you, Apple!

Wewease Bwian!

Because we've been able to test, I'm pleased to be able to provide those of you out there with the Release Candidate of SuperDuper! 2.8 as well. This has some minor changes as compared to the last update, based on the latest changes to El Capitan. It's nearly identical to what we're going to release next week to the public.

Not that you're not the public. Just that you're special, since you're reading this, and they're not.

Ch-ch-ch-changes

The main change is in our updater. Every task in SuperDuper is controlled by what we call a Transcript. The transcript coördinates the various parts of our code, Unix command-line tools, shell scripting, etc, to perform a task. One of those tasks is performing an auto-update.

Our automatic updater was one of the first out there, so it has a long history. And way back in the before time, OS X had a tendency to mess up permissions to certain folders when packages were installed. So, to help users out, our upgrade transcript fixed permissions for the Applications and Applications/Utilities folders.

The need for this diminished over the years, much like the need for repairing permissions, and we probably could have removed it. But it never hurt anything, and never caused a problem, so we didn't revisit the code.

Beta n

Of course, "never caused a problem" doesn't mean "never will cause a problem".

In a late Beta of El Capitan, "never caused" was automatically updated to "now causes", because changes to ownership and permissions for those folders (even if changed to the same values) became illegal...and that caused our transcript to fail.

We've fixed that in this update. But that fix isn't in the current version of SuperDuper, it's in version 2.8... which means users need to upgrade to 2.8 before they install El Capitan, or install manually.

We've adjusted the messaging in the update message to say this, so hopefully it won't be a big problem. But it won't be a problem for you because, again, special!

Wrapping up

That's about it! There are some other minor changes, but nothing to get worked up about. I think you'll find this version runs quite smoothly.

Download away!

Thanks to all of you for your help and patience while testing these releases, and thanks to everyone who reported problems.

Oh yeah? Well, lock *this*! Monday, August 17, 2015

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!

From Hell’s Heart I…Oh, Never Mind! Tuesday, July 14, 2015

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!

Uncovering our rootlessness Thursday, July 09, 2015

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!

SuperDuper - Now with added Superness! Wednesday, November 19, 2014

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!

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 3 of 24 pages « First  <  1 2 3 4 5 >  Last »