Some Client Applications Fail When Writing to Windows NTLast reviewed: November 19, 1997Article ID: Q124916 |
The information in this article applies to:
SYMPTOMSSome applications running from a Windows for Workgroups or LAN Manager client fail when they attempt to write to a file located on a Windows NT version 3.5 server (whether it is a Windows NT Server version 3.5 or a Windows NT Workstation version 3.5 machine acting as the server). The application may report this error in various ways, such as reporting a sharing violation, reporting that they cannot write the file, and so forth. These same applications, however, do not fail in this manner when they write a file to a Windows NT version 3.1 server.
CAUSEThere is an optimization in Windows NT version 3.5 which controls whether or not a file is actually closed on the server when requested to do so by the client. This optimization is controlled by the Registry parameter, CachedOpenLimit. If the server owns an oplock on a file when the client closes it, although the server will return the Close Server Message Block (SMB) response indicating that the file has been closed, it will keep the file open locally (that is, it removes the RFCB, but maintains the LFCB and does not issue the local NtClose() request), on the assumption that the client may soon reopen the file. If the client does reopen the file, this greatly reduces the time required to respond to the request. This optimization may fail to work correctly depending on how the file has been opened by the application. In many cases this can only be determined correctly by analyzing a trace of the network traffic between the client and the server while running the application. However, a quick test can be performed by disabling this optimization and not caching open files. To disable caching open files on the server as a test, follow these steps:
WARNING: Using Registry Editor incorrectly can cause serious, system- wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk. 1. Start the Registry Editor (REGEDT32.EXE) 2. Find the following key: \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \LanmanServer\Parameters 3. Add the following entry: Value Name: CachedOpenLimit Data Type: REG_DWORD Data: 0 NOTE: The default value for CachedOpenLimit is 5 remote file control blocks (RFCBs) per connection. 4. Exit the Registry. 5. Shutdown and restart Windows NT. WORKAROUNDYou can work around this problem by using the above directions to disable the CachedOpenLimit optimization.
STATUSMicrosoft has confirmed this to be a problem in Windows NT version 3.5. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.
|
Additional query words: wfw wfwg prodnt 3.50 access denied share locked
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |