I have a FAS960 and an R200 to deploy. One of the services to be provided is user file services. They will replace Windows servers, which also run MS's AFP services for Macs. The Mac users can currently share files fairly seamlessly with Windows users courtesy of (of all entities) Microsoft.
<rant> Despite the decade or so that has passed since everyone stopped thinking it was cool and pretty much started agreeing that it was a bad idea :-), Mac files are still three-dimensional entities with "data forks" (files), and "resource forks" (Mac-specific "stuff"). <sigh> </rant>
Apple file servers run a hierarchical file service that will store Mac files or flat files. (Duh.) Microsoft's AFP service also has a facility ("NTFS Streams") to handle the additional information, serve it up to Macs, and allow non-Macs to ignore it, while still presenting a single file image. Good enough.
Based on sparse clues, I *think* that all Data ONTAP releases post-6.4 support NTFS Streams in the same way as Microsoft AFP.
The Thursby products "DAVE" and "ADmitMac" are smart enough to notice that the NTFS Streams facility exists on the NetApp and make use of it, therefore files stored with these products vis CIFS appear as a single file on disk, and the Mac users still get their resource fork data back.
Unfortunately,... Apple's CIFS client is not so bright. It's not smart enough to realize that NTFS Streams is present, or to do anything clever with it. Instead it stores a separate file for the resource fork, i.e.:
._resume.doc resume.doc
It *is* smart enough to tag the "._" files as hidden in CIFS, but curious Windows users can see and manipulate them anyway. (We even tested with the yet-to-be-released rev of MacOS X, in case anyone is curious.)
Worse, the creating Mac user leaves the "._" file "in use" until it drops the share or shuts down, so other Mac users can edit the corresponding file, but not save it with the same name. Other tests showed the opposite: two Macs with the same file open r/w, happily overwriting the same Office document in turn. ACK! Macs can't share with Macs!
We tried Mac via NFS as well as an Xserve accessing via NFS and re-serving AFP to Macs. Both are worse, because the "._" files are then not marked as hidden in CIFS, so the Windows users see all of these junk files sorted to the top, before the "real" files.
Finally, the question! What are we missing? Is it really this ugly to share between Macs and PCs on a NetApp?
We really wanted to roll out this whole deployment server-side and relatively transparently; now we are looking at having to install ADmitMac on about 700 Macs. I'm hoping that there are some other options out there.
Thanks for any ideas, folks!
/// Rob
Rob -
Thanks for the email. We've been struggling with this problem for the last month when a couple of our users accidentally discovered that they couldn't share files using our filer. They both use Macs running OS X.3.8. We were banging our heads against the wall until your email pointed us in some new directions.
If we're looking at the same problem (and I think we are) then this appears to be more of an Apple problem than anything else. It has been around for a while and affects real Windows servers, SAMBA servers, and Net App boxes. Here's a link to a semi-old but very long and detailed thread from Apple's discussion board about the issue.
http://discussions.info.apple.com/webx?128@275.dmEkaYLETv1.1@.68947f81
It appears that the Mac software is not releasing the "._" file. What appears to be interesting is the final post (on page 2) which claims that upgrading to SAMBA 3.0.9 fixed the problem. This might have additional logic in the file handling routines to make sure that the resource forks are closed as well. Then again, here's another link to a newer post which claims to see the same problem with SAMBA 3.0.9-1. Go figure!
http://discussions.info.apple.com/webx?14@275.dmEkaYLETv1.1@.68a76759
We're currently trying to find a spare system to install OS X.4 on to see if that has the same behavior.
As an aside, it appears that there are two "workarounds" that we've come up with: 1. Close the connection to the server after saving the file. This appears to close everything and allows the other user access. 2. Edit the file locally and then copy the file to the server.
Hope this helps.
Pat Allen (pat@mbari.org & http://www.mbari.org/staff/pat) Monterey Bay Aquarium Research Institute (MBARI) 7700 Sandholdt Rd, Moss Landing, CA 95039 (voice) 831-775-1724; (fax) 831-775-1620
Rob Winters wrote:
I have a FAS960 and an R200 to deploy. One of the services to be provided is user file services. They will replace Windows servers, which also run MS's AFP services for Macs. The Mac users can currently share files fairly seamlessly with Windows users courtesy of (of all entities) Microsoft.
<rant> Despite the decade or so that has passed since everyone stopped thinking it was cool and pretty much started agreeing that it was a bad idea :-), Mac files are still three-dimensional entities with "data forks" (files), and "resource forks" (Mac-specific "stuff"). <sigh> </rant>
Apple file servers run a hierarchical file service that will store Mac files or flat files. (Duh.) Microsoft's AFP service also has a facility ("NTFS Streams") to handle the additional information, serve it up to Macs, and allow non-Macs to ignore it, while still presenting a single file image. Good enough.
Based on sparse clues, I *think* that all Data ONTAP releases post-6.4 support NTFS Streams in the same way as Microsoft AFP.
The Thursby products "DAVE" and "ADmitMac" are smart enough to notice that the NTFS Streams facility exists on the NetApp and make use of it, therefore files stored with these products vis CIFS appear as a single file on disk, and the Mac users still get their resource fork data back.
Unfortunately,... Apple's CIFS client is not so bright. It's not smart enough to realize that NTFS Streams is present, or to do anything clever with it. Instead it stores a separate file for the resource fork, i.e.:
._resume.doc resume.doc
It *is* smart enough to tag the "._" files as hidden in CIFS, but curious Windows users can see and manipulate them anyway. (We even tested with the yet-to-be-released rev of MacOS X, in case anyone is curious.)
Worse, the creating Mac user leaves the "._" file "in use" until it drops the share or shuts down, so other Mac users can edit the corresponding file, but not save it with the same name. Other tests showed the opposite: two Macs with the same file open r/w, happily overwriting the same Office document in turn. ACK! Macs can't share with Macs!
We tried Mac via NFS as well as an Xserve accessing via NFS and re-serving AFP to Macs. Both are worse, because the "._" files are then not marked as hidden in CIFS, so the Windows users see all of these junk files sorted to the top, before the "real" files.
Finally, the question! What are we missing? Is it really this ugly to share between Macs and PCs on a NetApp?
We really wanted to roll out this whole deployment server-side and relatively transparently; now we are looking at having to install ADmitMac on about 700 Macs. I'm hoping that there are some other options out there.
Thanks for any ideas, folks!
/// Rob
-
Pat Allen -
Rob Winters