Storage Vendors Drop the Ball on Lion Support

 
 
P. J. Connolly began writing for IT publications in 1997 and has a lengthy track record in both news and reviews. Since then, he's built two test labs from scratch and earned a reputation as the nicest skeptic you'll ever meet. Before taking up journalism, P. J. was an IT manager and consultant in San Francisco with a knack for networking the Apple Macintosh, and his love for technology is exceeded only by his contempt for the flavor of the month. Speaking of which, you can follow P. J. on Twitter at pjc415, or drop him an email at pjc@eweek.com.
By P. J. Connolly  |  Posted 2011-07-22 Email Print this article Print
 
 
 
 
 
 
 

I have my own beefs with Lion, but something has surfaced that's much more important than my petty concerns: the Time Machine backup tool in Lion doesn't work with many NAS devices. Now, I'm surprised that there's a problem; big OS releases always break third-party stuff, and in this case, it's a conflict between Lion's implementation of the Apple Filing Protocol, which includes the mechanisms that make Time Machine possible, and the software on these devices which interprets AFP.

hero_timemachine_lg

Lion's Time Machine backup tool isn't working with most NAS devices, and everyone dropped the ball on this one.

It turns out that third-party NAS devices typically make use of the open-source Netatalk project to provide AFP services such as Time Machine, and the changes made in AFP for Lion - specifically, the move to drop support for DHCAST128 authentication - are reflected in Netatalk 2.2, which is all but complete. This process took far too long, if you ask me; after six months of relatively rapid development, in which Netatalk 2.2 went through nine revisions (from first alpha to fourth beta), things stalled in April, when the last beta was posted, with little progress recorded in the three months since.That's because, from all appearances, there is only one developer in the world contributing to Netatalk, NetAFP's Frank Lahm. I've never believed that throwing more bodies at a project makes it go more smoothly, but this is ridiculous. I can't believe that the Ciscos and the EMCs of the world can't spare the time of a developer or two to advance the project, and thereby make their consumer and SMB products more usable, and sooner than currently possible.

For example, take the Iomega StorCenter PX4-300D that I'm currently evaluating; as of my conversation today with Iomega's people, the company expects to release Lion support for the PX series by the end of August, which is kind of late to the game, given how rapidly end users are implementing the new version of the OS. Let's be conservative and say that Iomega spends six weeks testing firmware before it becomes generally available for download. At least in theory, that would have meant that Netatalk 2.2 would have had to be ready for prime time by early June, in order to be incorporated in a firmware revision to be available this week. As it turns out, Netatalk 2.2 will "soon" be released, according to Lahm's latest post on the project site, and it's likely that vendors will be rolling out updates for their storage devices over the next month or so, as Iomega is planning to do.

Now, it's not Apple's responsibility to support Netatalk, although doing so would certainly be in the interests of its customers. If anyone needs to be stepping up to the plate on this, it's the storage vendors, as the ones with the most to gain from advancing the project. Until they do so, we have to put up with more of this nonsense.

 
 
 
 
del.icio.us | digg.com
 
 
 
 
 
 

Submit a Comment

Loading Comments...

 
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel