I think it was around Leopard's release--which seems like forever ago--that we ended up being later than expected with an update to SuperDuper. Since we've missed our internal target for release of 2.7.2, I thought I'd write a quick blog post to fill you in on what's going on, and why we haven't released the update yet.
First off, the update we have in external beta right now has been working really well for quite a long time. We're basically getting no reports of failures, which is a good thing, since it confirms internal testing.
However, we noticed two things in 2.7.1 under Mavericks, being used by the broader population, that we needed to fix.
The (demonic) MDS Daemon
As some of you may know, Spotlight's indexing daemon is called "mds", and runs automatically. It's loaded by launchd, and does its thing transparently, at low priority. Most of the time you won't even notice it.
In the past, we've temporarily turned mds off with mdsutil during the SuperDuper copy to stop it from indexing the backup during creation.
Which was fine, until we were hit by that dog's big wave.
Under Mavericks, on a few systems, mds seems to be crashing (in some cases it's been unloaded, rather than using the Privacy tab of the Spotlight preference pane). When this happens, mdsutil now throws an error, indicating that it can't talk to the daemon, and we stop. Re-running will often work (since mds gets reloaded), but it's intermittent and annoying.
We're going to stop disabling mds in 2.7.2 to work around this problem. Remember, you can always disable Spotlight indexing of a backup with the Privacy tab in the Spotlight preference pane (as long as you're using Smart Update): something I'd generally recommend since it also prevents backup results from showing up in a Spotlight search.
Extended Attributes of Unusual Size
Way back in Tiger (as I recall, it's been a while), Apple added Extended Attribute support to HFS+. The pretty standard getxattr/setxattr/listxattr calls were supported, and we've been using them to copy the attributes ever since their introduction. Mostly, they used to be small.
These days, Extended Attributes can be quite large (compressed files are actually stored, in some cases, in the resource fork EA), so we've always tried to copy them 256K at a time (to avoid allocating gigantic amounts of memory--they can be up to 2GB in size). This seemed to be fully supported by the get/set APIs, and worked fine.
However, in Mavericks, we started getting ERANGE errors on some (again, very few) user systems.
It turns out that the failure happens when a non-ResourceFork EA turns out to be larger than our 256K buffer. These are super rare, but we've found a few users who had PDFs with kMDItemComments that were gigantic (on the order of 2MB) and some GIFs with corrupted kMDItemWhereFroms that were huge and contained image data.
After carefully reviewing the code along with the current version of the man page (a tip of the pocket to Rich Siegel for helping out with a code review), we've determined the cause of the problem, and it's definitely our bug.
Basically, the com.apple.ResourceFork EA, where large compressed file data is stored, supports chunked reads and writes. Surprisingly, other EAs do not (even though they can be just as large, as mentioned above), and thus must be copied in one go, even if they're as large as 2GB. We were trying to copy them 256K at a time, which failed as soon as we went to the 2nd chunk, and we'd never hit a large, non-ResourceFork EA until Mavericks' release.
This took much too long to figure out. But now that we've determined the cause of the problem, and have fixed it in a way that maintains efficiency (and doesn't unnecessarily bloat our memory footprint), we'll have one more beta build and get the result, assuming success, into your hands.
Thanks for your patience. While you wait, you can try to diagram the last, terrible sentence of the previous paragraph. Good luck!
