The information in this article applies to:
SYMPTOMS
Any application that uses the AFP command CatSearch, such as the Macintosh
File Find, may reduce the server's responsiveness to other Macintosh
clients on the network, causing them to appear to stop responding for a
brief period of time.
CAUSEIn Windows NT 3.51, support for the AFP CatSearch command was added. This command is used so the Macintosh client asks the server to do the search, rather than performing the search of the Macintosh volume itself. CatSearch instructs Windows NT to look through all directories and files, based on the specified search parameters. When this search is performed at the root of a Macintosh volume with many directories, subdirectories, and files, it can delay the processing of requests from other Macintosh clients and the Macintosh clients will appear to stop responding while they wait for their request to be processed. RESOLUTION
To Disable CatSearch for a particular SFM volume:
STATUSMicrosoft has confirmed this to be a problem in Windows NT versions 3.51 and 4.0. This problem was corrected in the latest Microsoft Windows NT 4.0 U.S. Service Pack. For information on obtaining the service pack, query on the following word in the Microsoft Knowledge Base (without the spaces): S E R V P A C K MORE INFORMATIONHow AFP CatSearch WorksThere are several ways Macintosh clients search a remote volume. One way is to use Enumerate, which looks similar to Microsoft's FindFirst, FindNext, which is a client-based search. This method puts responsibility on the client (and some stress on the network). Another way is for a client to send a server-based command, CatSearch, which puts all of the responsibility and stress on the server. This method is used by most Macintosh applications, such as the FindFile utility, by default. This command, in effect, makes the Services for Macintosh (SFM) server do the file search on behalf of the client. The way SMF is designed on Windows NT, other users are locked out of the volume until the search is complete. If the Macintosh volume has a large number of directories and files (number of directories makes a bigger impact), and the search is started at or near the root of the volume, the search may impact other users. This becomes an issue because of the way the Macintosh operating system performs network I/O. The Macintosh uses synchronous calls to the network, and any delay in response from the server causes the Macintosh to stop responding. The Macintosh File Find interface allows users to search sub-directories, but the default is the entire volume and the other option isn't very obvious. This causes most file searches from the Macintosh to be done on the entire volume. If applications and users were more selective, file look-ups would not impact the system.Possible Affect of Disabling AFP CatSearch on the ServerWhen the AFP CatSearch command is disabled, Macintosh clients may experience long delays when performing Find File from the Macintosh desktop. The delays can be significant. A Windows NT server performing the AFP CatSearch request may lock the SFM volume for only a few moments, but when AFP CatSearch is disabled, a client may take several minutes, or more, to complete the same task. When disabling the AFP CatSearch command, users are advised that, if they do initiate a Find File, they may expect delays or long hangs while the Macintosh is performing this task.If a Find File is used with care, then disabling the CatSearch may become unnecessary. Users who need to perform the Find File should narrow down their choices to a few directories, rather than searching an entire volume. Also, extremely large volumes with lots of subfolders can increase the problem. If the File Find is being used constantly to access information, consider using a text file with the path to the needed file or a database that keeps a list of files in a particular volume. These methods can significantly improve server response. Additional query words: prodnt sfm
Keywords : kbnetwork ntmac kbbug4.00 kbbug3.51 kbfix4.00.sp2 |
Last Reviewed: January 29, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |