Turns out, a few of you have drives that don't have low-level media IDs...something we thought all drives had. And they did, at least, all the drives we and the external testers tried did.
Well, now we know...and, now we don't crash. Sorry about that.
Fix now available in v3.1.4 - download away!
Way back when, not so long ago, we transitioned the main SuperDuper! application to 64-bit. As I said then, we were 95% 64-bit, and 5% 32-bit.
Today, we're releasing SuperDuper! 3.13, which—after extensive testing—moves the copy engine to 64-bit as well. macOS 10.13.4 is going to start giving obnoxious warnings about 32-bit app usage, so we figured this was a good time to release the update, even without any significant user-facing feature changes.
I'd love to use this blog post to tell you that, because we're now 64-bit, we're 200% faster, but, well, no. Internal testing shows no significant gains or losses from being 64-bit. In fact, we have to do additional work packing and unpacking some file system structures, which are laid out (for legacy reasons) for 32-bit apps.
Of course, we fixed a bunch of other things, too. One specific change was to improve handling of source drives with bad recovery volumes.
We're not sure how people's drives get like this, but sometimes there will be a number of "Untitled" 650MB volumes on their drives. Disk Utility will indicate one of them is the Recovery volume, but when we try to mount and copy from it, we get an error, because the drive is bogus and can't be mounted.
Previously, we would stop and give an error. Now, we log the problem and generate a warning that explains how to resolve the problem. (Basically, you need to reinstall the OS, which refreshes the OS under your existing applications and data, and recreates/fixes Recovery.)
While we were at it, we fixed a few things in the last 10.9 compatible version (3.1.1), back ported some other fixes we made in 3.1.2, and updated it. Unfortunately, since it already had a version number, I just updated the binary. Bad form, I know, since there are now two 3.1.1s out there. But if you're using Mavericks, and can't create schedules with your existing 3.1.1, download 3.1.1 again and reinstall.
So yeah, we're older and we're losing our hair, but you really do still need us. Update inside the app, or download away!
Shipping software sucks.
It's not that we don't want to put the software in the hands of our users. And it's not that we're not proud of the work. We do, and we are.
What sucks is that you always ship with bugs. Always. Some of them you know about. Some of them you don't.
Anyone who does this for a living knows how this works. You keep track of everything you find in the software. Some things are reproducible. Some things aren't. You draw up general approaches for investigation for the latter, and propose fixes for the former.
You then prioritize things, hash out a schedule, and decide what's worth fixing and what you can, in the end, live with...for now.
During the run-up to SuperDuper v3.1.2 (available today, see below), we were dealing with this whole investigate-prioritize-allocate-test cycle, when someone brought a sheet to our attention that's been a known low-priority thing for years.
12 years, to be precise.
It's the basic "Stop the copy in progress" sheet that comes up when you want to stop a copy. It's something you can do by accident, and throw away a lot of progress, so we show a sheet that asks you whether you really want to stop.
Sensible, as far as it goes. But during the development of 2.0, there were a lot of potential cases that would have to be dealt with during a cancel, and while we were working through them, and how to present them to the user, a temporary cancel sheet was put in place.
A sheet that was immediately logged as "this has to be fixed" in our tracking database, because it was poorly worded, confusing and (please don't hurt us) had "Yes/No" buttons at the bottom. Enjoy this example of our overwhelming UI genius:
So many problems with that sheet. It's wrong, it uses crazy terminology, it doesn't match the rest of the app, it uses Yes/No buttons. I don't even...
There was a lot to do for v2.0, and development proceeded, other tasks took precedence, this sheet isn't used very much, and eventually we shipped 2.0 with the sheet in place, with the bug tagged as low-priority, known-terrible, embarrassingly bad, "we need to fix this post 2.0".
That cycle repeated over and over. It was an easy fix, but other things took precedence. This stuff happens. Shipping software sucks.
Well, it was terrible, and it's now 12 years post 2.0. So for the new year? Start celebrating, because it was fixed.
This version also fixes a bunch of other relatively minor things that should please one or more of you:
General cleanup, nothing too exciting, but a fix is a fix, and now they're available to you. Download away!
