Little by Little
It’s been about a month since the last update (it’s nice to have a little time to breathe), but it’s time to put out a bunch of little fixes and improvements. They’re pretty minor changes, but worth getting out there, so here we go!
September Gurls
There are some small bug fixes in the scheduler (mostly having to do with time changes with non-daily copies), but the “big” visible change is the ability to turn on a per-source summary.
A few users have written in who missed the old Scheduled Copies window, because it was a “one stop” location for scheduled info: you could see what had run, and when the next run is due, pretty easily.
SuperDuper 4 breaks things down a bit differently, and while it’s easy enough to see the jobs for a given source, the info about schedules was relatively diffuse if you had a lot of sources.
In the new update, you can turn on a Last Copy and/or Next Copy indicator in the source list control. As you might expect from the name, this shows when the last copy for this source ran (and whether it failed or succeeded), and also when the next copy is due.
This was actually part of the original SD4 design and mock-up, and I didn’t implement it, because I thought it cluttered the UI too much. It’s currently optional, and defaults to off, so it shouldn’t bother those who don’t need the info…and I may re-evaluate its presentation in the future (mostly because I’m not entirely happy with it).
But, it’s useful, and should meet the needs of the users who miss the old window. If that’s you…let me know what you think.
Error handling
I’ve made a change to the way I handle error recovery for hardlinked files that may have a small performance impact, but was done for a good (albeit rare) reason.
Normally, SuperDuper copies a file to the destination “atomically”—that is, I copy to a temporary file, and on success, I delete the original and rename the temporary copy to the original name.
This ensures that an unreadable source doesn’t whack a usable file on the destination.
There’s a case where this isn’t done, though: a file that’s hard linked. Hard links are a file system feature where there’s one copy of the data, and a bunch of “pointers” to that data.1
Since those “pointers” are based on a file’s inode2, if I copied to a temporary file, deleted the original, and then renamed the temporary file to the copy, the inode would change, which would break all the links. So, for those files (only), I was writing over the destination directly.
But that means that a source error would clobber the destination.
Given the mix of hard linked files (not too many) and the likelihood of the source generating errors, this is obviously the edgiest of edge cases, but…I figured I should deal with it.
So, now, I copy to a temporary file…and once successful, instead of renaming, I copy it over the original to preserve the inode. An extra step, but it maximizes safety.
Other stuff
Yeah. There’s other stuff, too. And you’ll discover it when you
or use the built-in updater.
As always, thanks for using SuperDuper!