NO! The files are not damaged beyond repair!!!!

The cause of this is related to the different methods AFS and SMB use to keep track of a file's resource fork and HFS+ metadata (like file type and creator type) which aren't supported natively by the PC.

Please do not waste your time trying to go the "salvage these files by adding a filename extension" approach that many might suggest, or into believing that your files are some how damaged beyond repair. They are not damaged! They're simply in a format that SMB can't handle.

See Marcel Bresink's excellent page on his "Fork Server Helper" application. <http://www.bresink.de/osx/ForkServerHelper.html>

The trouble that's occurring in your situation is that when you use the PC to run SFM, your lovely Windows server uses its own way of dealing with Mac resource forks, which are supported, in a sense, at the very core of the NTFS file system itself, which supports forks. This method is different than the "Apple Double" method OS X uses when it writes to a Windows server connected via SMB. They're not cross-compatible.

This is directly from his help files (which I couldn't find online, but which are too excellent not to post):

"Problems arise in this situation because the three file sharing standards supported by Mac OS X use a different way of handling and encoding Macintosh resource forks:

AFP can handle Macintosh resource forks natively.

NFS does not support Macintosh resource forks by default but Mac OS X emulates resource forks on NFS file systems using hidden "dot underscore" files. If the original file is called Sample, the resource fork is saved into a second file with the name ._Sample.

CIFS/SMB will also be treated using "dot underscore" files as explained above, when Mac OS X is writing Macintosh files using this network protocol. Additionally, CIFS/SMB is capable of supporting multi-fork files when it is used with the professional line of Microsoft Windows operating systems (Windows NT, Windows 2000 and Windows XP): If you use AFP to store a file on a Windows file server which can be done by using Microsoft Services for Macintosh (SFM), Windows will use a representation of the resource fork which is different from that of a native Macintosh system. However, if you later use CIFS/SMB to copy such a file back to a Mac OS X file server, the SFM representation of the resource fork will not be reconverted to a native representation. Windows and Mac OS X will leave the representation as it is. If the original file has the name Sample, resource fork components are stored to three additional files with the names Sample:AFP_afpInfo:$DATA, Sample:AFP_Resource$DATA and Sample:Comments$DATA."

So your solution is to get the PC server with its SFM back up and running, or perhaps use Fork Server Helper to try to attack it from the Mac side of things.

Hope this helps....

jcoman

Replied in the following topics

Could not open &quot;file name&quot; because it is not the right kind of document

Could not open "file name" because it is not the right kind of document