Problem with Services for Macintosh

[Editor's Note: Do you have something to share with other Windows NT Magazine readers? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (700 words or less) to [email protected] along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.]

If you copy or move files to a Macintosh volume on a Windows NT server, the Mac clients on the network might not be able to see these files, even though the PC shares can. This problem, which happens with multiple versions of the Mac OS, lies with the volume index file that tells the Mac clients which files are available on the networkshare. You can intentionally corrupt this index file and force NT to rebuild it so that the Mac clients can see the files you copied or moved.

If the problem exists in a volume that is part of a directory (e.g., d:public), use the following command syntax at the command prompt:

dir > D:PUBLIC:AFP_IdIndex

If you're rebuilding a root drive share (e.g., d:), use the following command syntax:

dir > D::AFP_IDIndex

If your path includes spaces, you must enclose the path in quotes. So, if the Services for Macintosh (SFM) directory in the above example was I:Mac Volume, you would use the following command syntax:

dir > "I:Mac Volume":AFP_IdIndex

Note that this command will intentionally corrupt the Macintosh volume index. When you stop and restart SFM, the corruption forces NT to immediately rebuild the volume index file. If you see an Access Denied error message, files might be open on the volume or PC users might be accessing the shared directory. Disable all programs and file sharing to prevent this error.

After NT finishes rebuilding the index, the OS will log an event in NT Event Viewer. If the volume is large, it might take several minutes before the Macintosh client can see all volumes and files. Avoid stopping the SFM service during this time.

—Jan Strnisko
[email protected]