NT File System and Services For Macintosh

Summary: How the Windows NT File System (NTFS) manages Macintosh files. Illustration of the problems encountered when trying to access a volume handled by SFM on a NTFS drive and presentation of the solutions we propose.
 

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.

Mac2SFM, a new utility

Nevertheless, all network administrators managing one or more NTFS/SFM servers are always looking for a good solution to the daily problems encountered in the management of data files and other files.
We present on another page our new Mac2SFM utility. This little program allows to convert BinHex files, MacBinary files, AppleSingle files and AppleDouble files to the streams used by NTFS/SFM to store the Macintosh files.

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

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.

 
Pierre Duhem (ex-Logiciels & Services Duhem)
3, rue Pierre Haret - F-75009 Paris (France) - Tel. (+33) [0]149 700 455
web: http://www.macdisk.com