Well, v3.7.1 didn't last very long, did it. >sigh<
Happy to announce SuperDuper! v3.7.2, the "give me a fix, one fix only" release.
Ready for Launch
Here's the deal: when Applescript starts SuperDuper with a specific Apple Event ("launch"), SuperDuper starts and doesn't load the default settings. Instead, it waits for the application scripting it to load the settings it wants, and proceeds from there.
Late in the development of v3.7.1, we ran SuperDuper! through the Xcode static analyzer, and it mentioned that one specific thing in our launch sequence could hang. So, it was moved off the main thread to a background thread.
Initial tests showed things worked, and the analyzer was happy, so we went with it.
If a Bug Happens in the Forest...
Well...I noticed that I received a weird error panel during a scheduled copy that showed that a volume wasn't mounted (which was true, but didn't matter). The copy happened fine, and it was kind of harmless, but it was weird.
That, though, was the result of the moved code...the launch event was loading settings it shouldn't, and if the drives for those settings were missing, you'd get an error.
Now, no users reported the problem, but we found it, fixed it, and that's v3.7.2.
Code is Served
That's about it! I'd love to say "100% Faster!" or "Tastes Great, Less Filling!" but really it's just "a bug was fixed".
And now SuperDuper! v3.7.2 is available for automatic update. Enjoy your weekend!
I'm happy to announce the immediate availability of SuperDuper! v3.7.1, an update that will go down in history as being released today. >fanfare<
So, what's different?
As is tradition around these parts, after the release of a major OS, and our corresponding major update to support it, there's always something that can be improved. Even with extensive private and public testing, there are just so many different Macs, software configurations, peripherals, drives, drive firmware versions, docks, raw drive units...something always pops up.
And so it has. In Ventura, on some systems, we've seen some cases where, post-replication ("Erase, then copy" in Big Sur and later), the destination volumes wouldn't always re-mount. Sometimes an error would occur (referencing the 'bsd' info), sometimes not. When these failures occur, Apple's replicator has also replicated the source volume name, and due to the error, we didn't get a chance to rename it back to what's expected.
Anyway, it was annoying to you and (because we hate things like this) us. So we've been working for the last month or so to try to find a way to fix this...and I'm happy to say we have.
But the excitement doesn't stop there.
What's in a name?
A recent Ventura release has also started notifying people about "Startup Items" that were installed. Of course, as you might expect, when you set up a schedule, we have to install some items to get those schedules to, you know, run and stuff.
So, Ventura starts telling you that it happened. But - rather than use the Application name, it used the "Development Team Name"...and so people who see that "Bruce Lacey" had added some startup items...confusing everyone. (Bruce, as you'll see in the About box, is my partner in this endeavor).
Of course, this confused people, they turned the startup items off, and then schedules didn't work.
We've found the key needed to get the startup items to say something more sensible, and so now they'll say "SuperDuper!"—please don't turn them off! If you do, your schedules will not work.
No Emulation Needed
Finally, we've found a way to get the updater to not demand the use of Rosetta: something entirely unnecessary, given the SuperDuper! application works natively on Apple silicon. This'll make the update seamless for users on Apple silicon without Rosetta installed.
Whee?
Yeah, not terribly exciting, I know. But, important behind-the-scenes improvements that should make things better for everyone.
As always, thanks for being a SuperDuper! user, and enjoy the new update!
