Article ID: 147438 - View products that this article applies to.
This article was previously published under Q147438
This article has been archived. It is offered "as is" and will no longer be updated.
NOTE: Some products mentioned in this article are manufactured by vendors independent of Microsoft; we make no warranty, implied or otherwise, regarding these products' performance or reliability.
Microsoft Windows 2000, Windows NT, or Windows XP Server has a set of services named "Services For Macintosh (SFM)" that allow Apple Macintosh computers to transparently gain access to shared files and printers that reside on Windows servers. Windows 2000, Windows NT, or Windows XPServer also allows PC clients to gain access to these same shared files and printers. When Macintosh clients connect to a shared directory on a Windows server, SFM presents the files as though they were native to Macintosh computers. Likewise, when PC clients connect to the shared directory, the Windows server presents the files as though they were native to PC computers.
The file system used by the Macintosh Operating System is very different from file systems supported by Windows 2000, Windows NT, or Windows XP. As a result, file naming conventions and the structure of files differ considerably between these two systems. This article shows how SFM and Windows work together to hide some of these details, and explains how Win32 applications can properly handle files native to Macintosh clients.
File Server for Macintosh (FSM), which is part of SFM, allows Windows and Macintosh clients to create and open files on the same share by presenting the files to the clients with the naming conventions used by their operating systems. That is, regardless of which client actually created a file, it appears as a Macintosh file to Macintosh clients and a Windows file to Windows clients.
File NamesSome file names cannot be represented exactly when viewed by applications from both Macintosh and Windows systems because the Macintosh and Windows operating systems use different code pages to represent character strings and different file naming conventions. File Server for Macintosh works with NTFS to preserve the file semantics used by both systems by translating illegal characters in file names so that both Macintosh and Windows clients may access the same files.
Regardless of which type of client creates a file, NTFS stores its file name on disk in UNICODE format. When a Macintosh client creates a file on a share, FSM translates characters in the file name that are invalid on NTFS into equivalent characters in the user-defined range of the UNICODE character set so that the file name is legal on NTFS.
When a Macintosh client uses a file that it or another Macintosh client created on an NTFS share, it will see the original name. File Server for Macintosh maps the characters on disk from the UNICODE user-defined range back into their original Macintosh-specific characters.
When a Macintosh client gains access to a file created by a Windows client and that file doesn't follow the Macintosh file-naming standards, FSM maps the invalid characters into the equivalent characters in the Macintosh code page. The Macintosh client will then see the file with substituted characters in its name.
UNICODE-enabled Win32 applications will see file names with characters in the user-defined space and can open them without a problem. Windows-based applications that use the ANSI character set will see a second mapping from the user-defined UNICODE characters to the ANSI default character -- the question mark (?). Because the question mark is also a wild-card character on Windows platforms, Windows applications that use the ANSI character set will not be able to open these files.
NTFS will automatically generate short file name equivalents for long file names created by both Macintosh and Win32 clients so that 16-bit Windows and MS-DOS clients can gain access to them. The rules for automatic short name generation are the same as Windows uses any time a long file name is created on disk.
File StructuresWindows platforms represent files differently from the Macintosh Operating System. File Server for Macintosh handles these differences so that Macintosh clients see files as though they were native to Macintosh computers, and Windows clients see them as being native to Windows platforms. This section explains how files are represented on both operating systems and how FSM handles them.
Windows platforms do not define the structure or interpretation of any file's content; applications can impose any structure on the content. Except for a very limited case, all files consist of a single stream (linear sequence) of bytes. These files are called "flat" because they don't have any higher-level organization. Win32 applications running on Windows can create files with multiple streams on NTFS volumes only. However, as a general rule, they should not create files with multiple streams because they will be "flattened" when copied to volumes with the FAT file system.
Because Win32 platforms can use different file systems, the maximum file size depends on which file system is used. Files on the Protected-Mode FAT file system may have a maximum size of 2 gigabytes (GB). On NTFS, the largest file can be 17 billion GB long (2 to the 64th power bytes). Only Win32 applications running on Windows can access the full range of files larger than 2 GB.
The Macintosh Operating System uses files consisting of two linear sequences of bytes known as forks. The data fork is used to store the file's data and corresponds to a file created by a Win32 platform. The resource fork is used to store information about the file, such as its icon or the fonts used in it. Every file has both forks, but either or both may be empty.
As far as the Macintosh Operating System is concerned, the content of the data fork is unstructured and is subject to interpretation by applications. The resource fork has a definite structure imposed by the Macintosh Operating System and is used for file management purposes. The following diagram shows how a file created by a Macintosh is structured:
When a file created by a Macintosh is stored on a Windows server, it is stored in a single file that contains a stream for each fork. When Windows- based applications gain access to a file created by a Macintosh client, File Server for Macintosh presents only the data fork because the data fork is the equivalent of the representation of files on Windows platforms. Windows-based applications may not access the resource fork.
+--------File--------+ | | V V +------------+ +------------+ | | | | | Data | | Resource | | Fork | | Fork | | | | | +------------+ +------------+
The Macintosh Operating System allows files and volumes to be as large as 2 GB.
Design Recommendations for Win32 ApplicationsSome Win32-based applications running on a Windows server need to manage files that were created by Macintosh clients. Although File Server for Macintosh presents files as each type of client expects to use them, applications that manage files must do so correctly to preserve the file names and structure for Macintosh clients. This section presents the four most important design guidelines that you should follow to handle files properly.
File Name ReferenceA code page is a mapping of the numerical bytes (character codes) used to represent strings and their representation on the display (glyphs). Because Win32 and Macintosh systems use different code pages, some extended ASCII characters on one system are not representable on screen in exactly the same way on the other. For example, on the Macintosh, the glyph for character code 0xBD is the Greek Omega character while in the Windows ANSI code page, it is character symbol for "1/2."
The Macintosh Operating System uses the following file naming conventions:
"Inside Macintosh: Files," copyright 1992 Apple Computer, Inc.
"Services For Macintosh," Microsoft Windows NT Server product documentation.
"File Systems," Microsoft SDK overview.
Article ID: 147438 - Last Review: February 24, 2014 - Revision: 4.2