NTFS and File Streams
Under the New Technology File System, files are not necessarily monolithic, like under the FAT system, but can be composed of several named or unnamed streams. Those streams can be used for several purposes, and the Services for Macintosh (SFM) use them to store the Macintosh files without loosing their forks.

NTFS and Macintosh Files
Therefore, it is possible to store and recover independently both forks of Macintosh files. The SFM service stores a third stream to keep notice of what is generally called the Finder Information.
The fact that both forks can be retrieved doesn't mean that SFM doesn't encounter problems while storing the Macintosh files, and the list of the articles published by Microsoft in its Knowledge base is pretty long. Let me add nevertheless that those articles are mainly of historical interest and that the situation appears to be largely stabilized today, after a few years. Subscribe to the Mac-NT list if you want to share your experience and ask your questions on this matter.

Main Problems
It is possible to sort in several categories the problems encountered when the Macintosh files are not only saved and retrieved from Macintosh clients, but also from Windows clients:

• Allowable character set in Macintosh filenames
• Length of Macintosh filenames (31 characters)
• Understanding the Macintosh signatures
• Handling the resource fork of Macintosh files
• Transferring font files
• MacBinary standard

Allowable Character Set in Macintosh Filenames
In the Macintosh file system, the only reserved (prohibited) character is the ':', used as separator character in access pathes (like in "Macintosh HD:folder 1:folder 2:File").
Therefore, Macintosh users are accustomed to use all possible characters in the names they give to their files. Some of those characters are reserved in the PC file systems, amongst them '/' (0x2F), '\' (0x5C), ':' (0x3A), '>' (0x3E), '<' (0x3C), '|' (0x7C), '*' (0x2A), '?' (0x3F), '"' (0x22). The '§' (0x15 or 0xF5) brings some other problems and should also be avoided.
Some other frequently used characters are semigraphic characters like bullets and the like.
Those characters are naturally problematic in all file transfers. In the NT file system, they are stored as special Unicode characters (private range 0xF0xx). This solves the problem when the files are stored and retrieved from a Macintosh client. They have to be coded/decoded correctly when the files are transfered to a FAT volume. More, some features of the Explorer, like the compression, don't work with files or folders whose name contains such characters.
Our transfer tools do a sensible job while displaying those characters and of course when copying the files.

Length of Macintosh Filenames
The length of Macintosh filenames is limited to 31 characters. Those 31 characters were long considered as a huge freedom space, when PC users were still using the "8+3" filenaming scheme. Nowadays, the situation is quite the reverse: if you only add a file suffix to a 30-character long filename, the Macintosh client can't see the file any more and gets confused.
Some clever administrators had thought about a service running in the background and scanning all filenames on the shared volumes to strip the reserved characters and to add file suffixes. It is not so easy.

Understanding the Macintosh Signatures
In the Macintosh file system, the very nature of files is not stored in the extension or suffix added at the end of the filename, but is stored as a signature. This signature is stored amongst the Finder information, in one of the filestreams. Everything is perfect as long as the file is not accessed from a Windows station, or copied to a volume not handled by SFM. In this case, the file can't be opened by the right application by a mouse click.
There is a method to establish a lookup table in the registry, but it is cumbersome and not all administrators implement it. More, this only solves the problem when accessing the file from the shared volume. When the file is copied to a FAT volume or to a NTFS volume not handled by SFM, the link is lost.
Our transfer utilities use their own signature file to add correct file extensions to the files copied onto FAT or NTFS volumes. This signature file can be edited.

Handling the Resource Fork of Macintosh Files
The resource fork is used to store special elements of the files, like the code of programs, some graphical resources like icons, etc.
From the Windows station, it doesn't matter if you can't access the resource fork of an executable file, since it could not be executed on an Intel processor, anyway.
This is not true for some other files, like font files.
This is also not the case if you downloaded some Macintosh file on a PC and want to install it on the server to make it available to all Macintosh users.

Transferring Font Files
A Macintosh font file (True Type or Type 1 [PostScript]) stored on a NTFS volumes appears to the Windows user as an empty file. This is because the Explorer only lists the length of the data fork, which is empty. The real contents of the font file is stored in the resource fork.
Accessing the resource fork of a Macintosh file is not easy without some programming. More, font files are not directly usables and must be converted.
Our transfer utilities know how to manage font files. See our more general page on transferring fonts.

MacBinary Standard
Managing MacBinary files is just the next step. In this case, the program must manage in a single stream the data fork, the resource fork and the Finder information.
This protocol can be useful when you want to extract a font file or a program from a NTFS volume under SFM to put it on a physical Macintosh medium, or in the opposite direction to install on such a shared volume a MacBinary file downloaded from the Internet.
The MacBinary mode is one of the working modes of our transfer programs.

Screen Shots
We present some screen shots to show you the difference between what you see under the Explorer and what you can see and do with MacDisk.