AFP548

ADmitMac vs. Tiger

Thursby’s ADmitMac is a full-featured SMB/CIFS client that contains a lot of great features to hook Mac OS X into an Active Directory infrastructure. Be aware, though, that there is a downside involved. Thursby chose to implement a different method of handling resource forks on non-AFP filesystems than Apple uses in its samba-based SMB client. Basically, Thursby’s method takes advantage of multi-fork-savvy filesystems (like NTFS) whereas Apple’s doesn’t.

The upshot of this is that if you have two Mac clients, one using ADmitMac and the other using the "stock" SMB client, both accessing an SMB share, neither will be able to see resource forks saved by the other system. This is no big deal for some files (notably those with a known DOS-style 3-letter filename extension like ".doc" or ".xls"), but it can make other files completely unusable. For example, Eudora files rely on the type/creator codes in the resource fork; without the resource fork, Eudora doesn’t know what to do with the various files.

I quizzed a Thursby engineer on this incompatibility, and he pointed out that their DAVE product, which was the first SMB client for Macintosh, used this method because it adhered to Microsoft’s Services for Macintosh standard. They are simply carrying on the tradition of doing it the Microsoft-recommended way.

This incompatibility is a huge issue that Thursby seems reluctant to address. Thursby’s implementation may be superior to Apple’s on technical grounds; nonetheless, they need to either convince Apple to do it their way, or change ADmitMac (or at least offer an administrative option) to do it the Apple way. As it stands now, unless sysadmins go with an "all or none" approach to ADmitMac in their organization–now and into the foreseeable future–they’re asking for trouble. That’s an expensive prospect.

Exit mobile version