Day: 19 February 2014

(Partially) Recovering From a Bizarre iTunes Error Turned Catastrophic

In order of priority of intent, this is a post for me to reflect, for this error to show up in Google, and then — somewhere in the distance — for you, dear reader. As selfish as that may be, parts of this may interest you.

Last night as I popped my iPhone into its dock to sync, iTunes returned an “unknown error”, with code 1723. These code-based errors are unhelpful as-is, but the explanation and fix is usually a Google search away. For this one, though, there’s almost nothing documented. According to this list, error 1723 signifies “errAEAccessorNotFound: Accessor proc matching wantClass and containerType or wildcards not found”, whatever that means.

It’s a particularly bad error to be undocumented, too: it results in a fatal error during syncing. While a backup will be created, no further synchronization will occur. And, so, I dedicated some time to fixing this problem — quite a lot of time, as it turns out.

I started with the usual, simple stuff: restarting both OS X and my iPhone, reinstalling iTunes, reinstalling iOS (using the upgrade method, not restore), changing USB cables as this guy suggests, and so forth. All of these methods failed. I checked the standard OS X Console and saw no errors. While Xcode, on the other hand, displayed a far more verbose console, I saw no obvious errors. However, in the interest of this problem being fixed, I captured a few of these logs and submitted them to Apple.1

It was time to pull out the big guns and restore the iPhone. Unfortunately, a restore to a backup restored the mysterious error, so a clean restore was necessary, and that’s when everything went wrong for one simple reason: I encrypt my iPhone backups.

Encrypting your backups is generally considered a smart move. Not only is it more secure than a standard backup, it also includes all of your WiFi passwords. And, in an ideal world, the fact that all of the data is locked down isn’t ever a problem. Except when it is.

The good news is that a clean restore did fix this perplexing error. The bad news is that any document which existed only on the iPhone — that is, any document which didn’t sync to a cloud service — was now locked in an encrypted state. Despite my Google prowess and the legal grey-area predilections of various Cyrillic-filled websites, I couldn’t find a tool which would reliably extract an encrypted iOS backup or, if the tool did exist, it was Windows-only.

But that’s until I stumbled across Andrew Neitsch’s fantastic post on Stack Overflow. It’s a step-by-step guide to using a super easy Python script to extract an encrypted backup. And it worked.

So, keeping in mind that this is more for me and those who will find this via Google, here’s what I learned:

  1. Encryption isn’t a bad thing, but be well aware of what can happen if something does go horribly wrong.
  2. Keep multiple backups of your backups. Before attempting a restore, back up your iOS device, and copy that backup folder (located in ~/Library/Application Support/MobileSync/Backups/long-UDID-string) to a thumb drive or something. Because iTunes uses the UDID for the “name” of the backup, this folder will be overwritten when that device reboots and backs up for the first time, so you may potentially lose a lot of data.
  3. iTunes syncing and iTunes errors are still a real shitter in the Apple user experience landscape.
  4. Even if you can recover your messages, voicemails, call log, and so forth, restoring these files to the iPhone is nearly impossible.
  5. While some people advocate deleting local copies of apps to save space, keeping them around significantly sped up the restore process. I would have spent far more time with this restore had I been required to re-download each app.

One final twist: Vesper and VSCOCam, for example, both keep local non-cloud-synced document databases. After restoring my phone and reinstalling these apps — remember: not from a backup — all of these documents were restored. I’m not sure whether this is something new in iTunes or iOS, but it was a very welcome surprise after an evening of frustration.

  1. Radar number 16106365 if you’re interested, Cupertino-area readers. ↥︎

WhatsApp: The Inside Story ⇥ wired.co.uk

A fascinating in-depth look at the founders and the genesis of WhatsApp from Wired’s David Rowan. This bit, in particular:

So have governments demanded that WhatsApp gives them access to its servers?

“There really is no key to give,” Koum says. The US National Security Agency, he insists, has no access to users’ messages. “People need to differentiate us from companies like Yahoo! and Facebook that collect your data and have it sitting on their servers. We want to know as little about our users as possible. We don’t know your name, your gender… We designed our system to be as anonymous as possible. We’re not advertisement-driven so we don’t need personal databases.”

In hindsight, this will either look like a mantra or definitive credo, or it will look foolish.

WhatsApp’s Opinion on Advertising ⇥ blog.whatsapp.com

With today’s acquisition news, now seems as good a time as any to look back at founder Jan Koum’s views on advertising, circa June 2012:

At WhatsApp, our engineers spend all their time fixing bugs, adding new features and ironing out all the little intricacies in our task of bringing rich, affordable, reliable messaging to every phone in the world. That’s our product and that’s our passion. Your data isn’t even in the picture. We are simply not interested in any of it.

I’ll be surprised if that doesn’t change.

Apple Manager Mystique ⇥ bloomberg.com

Peter Burrows and Ian King, Bloomberg:

Apple Inc. is known for producing great products, like the iPod. Now Google Inc. with its acquisition of Nest Labs Inc. and its Apple alumni founder Tony Fadell, is hoping it produces great leaders who can replicate that success as well.

It’s a gamble that has proved disappointing for companies from Palm Inc. to J.C. Penney Co.

Burrows and King are, of course, referring to the hiring of Jon Rubinstein and Ron Johnson, respectively.

The premise of this article seems to be that hiring former Apple executives to run a division or a company isn’t the hole-in-one quick fix that it may seem, but Burrows and King don’t provide enough context as to why this is. Later in the article, they admit that there are former Apple employees who go on to great success:

Bertrand Serlet, who was Apple’s senior vice president of Mac software, co-founded a cloud-computing company called UpThere. Mike Matas, who worked as part of the original iPhone software design team, left to found Push Pop Press, which was acquired by Facebook Inc. Evan Doll, another member of that group, co-founded news-reading application company Flipboard in 2010.

There’s a key difference between the first group and this second one: Rubenstein and Johnson were brought on to try to fix companies that were already doing poorly.1 Fadell, on the other hand, belongs in the latter group of Apple employees who founded companies. None of the people in this category had the burden of trying to right a sinking ship, so they could get on with the job of making great products.

  1. The Rubenstein-led Palm produced the Pre, which was one hell of a great phone. Unfortunately, it wasn’t financially successful, but the UI ideas in WebOS continue to have an effect on mobile interface design. It was the Sunny Day Real Estate of operating systems. ↥︎