Executive Summary
Changes in macOS 10.13.4's behavior caused some problems for scheduling, and for the final steps involved in preparing an earlier major OS version's copy for boot. The beta resolves these problems (among others), and adds the ability to multi-select schedules in the Scheduled Copies window and run them all with one click.
SuperDuper! 3.1.5 Beta 1 Download
Replacing Gaskets
Setting up a drive for boot involves running the appropriate system tools, from that OS version, so that things are configured as the older OS expects them to be.
Unfortunately, 10.13.4 broke compatibility with earlier major macOS versions of update_dyld_shared_cache, causing the tool to crash on launch.
While the copies are fine, the error was, at the very least, disconcerting. This beta resolves that issue, at the cost of slower boot...or, potentially, the need to attempt the boot more than once the first time it's started from after a copy.
COSC Timing
When 10.13.4 was released, we also started seeing an increase in user reports of either "missed" schedules or schedules that didn't run until the user logged in. (Typically, they'd see SuperDuper! launched, unexpanded, and not running; the run would then start a few seconds after logging in.)
We tried a lot of different things to resolve this problem over a number of weeks, and finally hit on the multi-factor solution we needed to get things working reliably again.
Basically, it all came down to the system driving back to sleep before we had a chance to hold an assertion to keep it awake.
Unfinished Base Movement
In previous versions, our launchd job responsible for running our schedules would run on a repeating interval, every 60 seconds, and check to see if there was a job to run. While it was guaranteed to run once a minute, the second wasn't guaranteed, and thus could potentially be as late as 59 seconds past the minute.
I did this because, at the time, I couldn't figure out how to get a job to run every minute on the minute.
This meant that the wake, typically a minute before, could take more than two minutes before the real copy started...and the system would go to sleep before we had a chance to tell it not to (since we didn't want to tell the system to not sleep when we're just up, but rather while we're running a copy).
Chamfered Edges
The first attempt at this was to use caffeinate in the launchd job to hold the system awake in the background while the scheduled copy had a chance to get going. But, even though this worked in some testing, inside launchd it just didn't work: the assertion wouldn't persist.
As a second cut, we changed SuperDuper! to hold a brief assertion when launched. That helped somewhat...but didn't solve the problem.
To improve things, I delved into launchd some more, and (finally) figured out how to get our launchd job to run every minute, on the minute (for those who want to do this, you counter-intuitively use an empty dictionary). This helped even more: we can now set the wake event for the same time as the schedule...but it didn't fully resolve the issue, especially when users had a bunch of schedules set to run overnight.
Finally, we thoroughly investigated the internal script client scheduler: the part of SuperDuper! that sequences multiple AppleScript clients so they don't interrupt each other or all try to run at once. In there, we found some obscure logic errors that caused individual schedules to sometimes not start immediately, leaving them waiting in the queue for a while, even though they should have run right away.
Since this potential delay was longer than the sleep assertion we added in the worst case, the "real" assertion, set up during the actual copy, would sometimes never get a chance to take hold...and once again, the system would sleep. This resolved that problem.
Blued Screws and Gold Chatons
At the same time, we fixed a longstanding problem with "progress spinners" sticking around in the Scheduled Copies window even though the schedule was complete, and with schedule sequencing when more than one schedule was pending: now, if you space the schedules one minute apart, they're guaranteed to run in the order they're scheduled, rather than in a semi-random order.
And as a final bonus just-in-case we retain a "don't sleep" assertion as long as there are any pending AppleScript clients, to ensure that the system doesn't go to sleep before they get a chance to start their copies.
The sum total of all these changes: problem resolved (with even better behavior than before), and groundwork laid for future improvements as well.
Glashütte Stripes
For a finishing touch, we added in something we've wanted for a while: you can now select multiple schedules in the Scheduled Copies window and run them all on demand by clicking Copy Now.
There are a bunch of other fixes in here, too. We worked around another(!!1one!) very weird system pipe bug that was causing communication between the copy engine and the UI to break. This also improved the retrieval of error information from the copy engine.
We fixed a problem with file copying when a file was deleted out from under us between the data and attribute parts of the copy - now, we continue past that point, since the problem is pretty clear.
We fixed another problem where an image file might get recreated, rather than updated, in some situations.
And we finally turned off the spell checker for the log view (yeah, I know, don't ask), and improved its operation, so it won't scroll out from under you if you open it during a copy...and people won't think that the spell checker underlines are errors.
There are things I'm forgetting, but since we're already nearly 1000 words in...
Final Adjustment in Six Positions
We're pretty confident that this version will work great for you, as it's been tested on a broad spectrum of user systems, macOS versions, etc. To be sure, though, before we update the world, we've decided to release this as a Beta today. As explained in the beta post, if you install this, and we need to release updates to the beta, it will update automatically and separately from the release update feed. And when the final version is released, it'll also automatically become a "release version" and transition to the regular update feed.
So...have at it, and let me know how it works for you.
