In v3.2.2 of SuperDuper!, I introduced the new Auto Wake feature. It's whole reason for being is to wake the computer when the time comes for a backup to run.
Simple enough. No UI beyond the regular scheduling interface. The whole thing is managed for you.
But What About...?
I expected some pushback but, well, almost none! A total of three users had an issue with the automatic wake, in similar situations.
Basically, these users kept their systems on but their screens off. Rather inelegantly, even when the system is already awake, a wake event always turns the screen on, which would either wake the user in one case, or not turn the screen off again in the other due to other system issues.
It's always something.
Of course, they wanted some sort of "don't wake" option...which I really didn't want to do. Every option, every choice, every button adds cognitive load to a UI, which inevitably confuses users, causes support questions, and degrades the overall experience.
Sometimes, of course, you need a choice: it can't be helped. But if there's any way to solve a problem—even a minor one—without any UI impact, it's almost always the better way to go.
Forget the "almost": it's always the better way to go. Just do the right thing and don't call attention to it.
That's the "magic" part of a program that just feels right.
Proving a Negative
You can't tell a wake event to not wake if the system is already awake, because that's not how wake events work: they're either set or they're not set, and have no conditional element.
And I mentioned above, they're not smart enough to know the system is already awake.
Apple, of course, has its own "dark wake" feature, used by Power Nap. Dark wake, as is suggested by the name, wakes a system without turning on the screen. However, it's not available to 3rd party applications and has task-specific limitations that tease but do not deliver a solution here.
And you can't put up a black screen on wake, or adjust the brightness, because it's too late by the time the wake happens.
So there was no official way to make the wake not wake the screen available to 3rd parties.
In fact, the only way to wake is to not wake at all...but that would require an option. And there was no way I was adding an option. Not. Going. To. Happen.
Smart! Wake!
Somehow, I had to make it smarter. And so, after some working through the various possibilities... announcing... Smart Wake! (Because there's nothing like driving a word like "Smart" into the ground! At least I didn't InterCap.)
For those who are interested, here's how it works:
- Every minute, our regular "time" backup agent looks to see if it has something to do
- Once that's done, it gathers all the various potential schedules and figures out the one that will run next
- It cancels any previous wake event we've created, and sets up a wake event for any event more than one minute into the future
Of course, describing it seems simple: it always is, once you figure it out. Implementing it wasn't hard, because it's built on the work that was already done in 3.2.2 that manages a single wake for all the potential events. Basically, if we are running a minute before the backup is scheduled to run, we assume we're also going to be running a minute later, and cancel any pending wakes for that time. So, if we have an event for 3am, at 2:59am we cancel that wake if we're already running.
That ensures that a system that's already awake will not wake the screen, whereas a system that's sleeping will wake as expected.
Fixes and Improvements
We've also fixed some other things:
- Due to a pretty egregious bug in Sierra's power manager (Radar 45209004 for any Apple Friends out there, although it's only 10.12 and I'm sure 10.12 is not getting fixed now), multiple alarms could be created with the wrong tag.
- Conversion to APFS on Fusion drives can create completely invalid "symlinks to nowhere". We now put a warning in the log and continue.
- Every so often, users were getting timeout errors (-1712) on schedules
- Due to a stupid error regarding Summer Time/Daylight Savings comparisons, sdbackupbytime was using 100% CPU the day before a time change
- General scheduling improvements
That's it. Enjoy!
