A. The Windows 95 NET USE command for mounting shares from the command line does not allow mounting share names longer than servername and a single sharename element, (e.g. net use e: \\server\dirname\subdirname causes NET.EXE to return a syntax error). Windows 95 NET.EXE makes the assumption that all network providers will only want to connect to a single sharename element. This has been identified by Microsoft as an OS bug. Workarounds include mounting to single path element sharenames only, mapping the longer names from the desktop interface, or replacing all backslashes past the server\sharename separator with colons (e.g. from above, the syntax would be net user: \\server\dirname:subdirname).
A. The Windows 95 OS (MPR and the IFS Manager) limits the sharename that may be specified when mapping network drives. The last element of the sharename path cannot exceed eight characters. Also, NET USE does not maintain case on sharenames, so all NFSmount sharenames are forced to lowercase. These have been reported to Microsoft as OS bugs.
A. There is a problem with the way Windows 95 handles connecting to servers that support more than one protocol understood by the client. Once Windows 95 determines that the server supports Windows LAN Manager networking, the OS will never again try to access the server using NFS until the client is rebooted. This occurs with any Windows 95 client connecting to a server that supports multiple protocols along with LAN Manager, not just NFS. Windows 95 may make IPC (InterProcess Communication) connections to LANManager servers from time to time unrelated to Map Network Drive attempts that will block NFS access to multiple protocol servers. Windows 95 will never timeout its cache of servername to protocol once it determines a protocol the server supports on an access. This may also prevent LAN Manager access to the specific multiple protocol server once an NFS connection has been established. This has been identified by Microsoft as an OS bug.
A. In addition to enabling locking on the clients, locking must be available and enabled on the server being accessed. The lock manager on the server must also support Network Lock Manager version 3 because this is the only version that supports PC type lock requests.
A. Enabling locking will slow the client down in any case because of the extra network traffic required to support locking. However, there are cases where the slow down could be extreme. There are two reasons this could happen. Either locking is not enabled on the server being accessed or the server does not support Network Lock Manager version 3. In both of these cases, the client is attempting to contact the lock manager (version 3) on every access, timing out, and retrying. This behavior is required if the client is to recover automatically from a server crash.
A. Explorer is a 32-bit application and Windows 95 is case-preserving (but not case-sensitive) for 32-bit applications. When a 32-bit application lists files it may use the long filename when displaying names. When a 16-bit application like Winfile or Word displays filenames however, the short name is used (which may not be case-preserving). A short filename must be generated for one (or both) of the file(s) so they may be distinguished from each other.
A. This is due to a limitation in Windows 95. Windows 95 does not preserve case for directory names. This results in the DiskAccess client having to do a case insensitive search of a directory for mixed case file/directory names. This means the first file/directory name that matches when performing this search is returned leaving the second file/directory inaccessable.
A. When "Case Preserve" is selected, the DiskAccess client will not change the case when creating or renaming a file. Some 16-bit applications rely on the operating system to convert all file/directory names to upper case. These applications create and open files which differ only in case, assuming the same file is being accessed. However, the DiskAccess client will create separate files when "Case Preserve" is selected. This often results in application errors or corrupt files.
A. Although the DiskAccess client is capable of supporting long file/directory names, the server may not support long file/directory names. In many cases, the server may truncate the name when creating or renaming files and directories.
A. DiskAccess Network Provider DLL periodically issues a network broadcast to request a reply from each NFS server on the network. The name of each server that responds to this broadcast is placed in a list. This list is displayed when an application browses the NFS Network. By default, DiskAccess Network Provider issues this broadcast at system startup and again every five minutes. A new list of servers is generated with each broadcast. In this manner, servers that are no longer responding are eliminated from the list, and new servers are added to the list. DiskAccess may be configured to only issue the broadcast once, at system startup. This method reduces the amount of network traffic. However, the NFS server list will never be updated and, therefore, may become inaccurate if servers are removed from or added to the network. DiskAccess may be configured to only issue the broadcast when an application attempts to browse the NFS Network. This provides the most up-to-date list of NFS servers and only generates network traffic upon demand. However, this technique causes the browsing application to wait for the list to be generated. There is a configurable timeout value that specifies the length of time the DiskAccess Network Provider will wait to receive replies from NFS servers responding to the broadcast. By default, this timeout value is set to 15 seconds. This long timeout period allows servers that are slow to respond, such as servers on distant LANs, to be included in the list. If DiskAccess is configured to only broadcast upon demand, it is recommended that this timeout value be set to one second. Although this will prevent slow responders from being added to the list, this will improve the browse response time.
A. By default, DiskAccess Network Provider specifies the IP broadcast address 255.255.255.255 when issuing a browse broadcast request. This address indicates that the broadcast is to be sent to all nodes. If bridges or routers are present in the network configuration, the network administrator may have configured them to pass broadcast frames or filter them out. This will affect whether or not servers on remote LANs will appear in the NFS Network browse list. DiskAccess may be configured to specify a different IP broadcast address. For example, specifying the address 126.96.36.199 instead of 255.255.255.255 will limit the broadcast to the 129.135.102 LAN.
A. When an application browses the NFS Network, a network broadcast is sent to request a reply from each NFS server on the network. DiskAccess Network Provider allows the system administrator some control over this broadcast through the following registry values. These values are only read from the registry at system startup, therefore, it is necessary to reboot after changing these values to make them take effect.
SPBroadcastAddr (Default: 255.255.255.255)
This value may be changed to cause the broadcast to only be transmitted on the local LAN. For example, specifying 188.8.131.52 would cause the broadcast to only be transmitted on the 129.135.102 LAN.
SPBroadcastRetry (Default: 0)
This value may be changed to cause the broadcast to be transmitted several times. If a busy bridge or router on the network tends to drop frames, increasing this number may increase the likelihood that the broadcast will be passed through the busy device.
SPBrowseMethod (Default: 0)
0 - Broadcast at system startup and again every SPUpdateMinutes. A separate thread periodically issues the broadcast. This allows the list of NFS servers to be updated every SPUpdateMinutes.
1 - Broadcast at system startup only.
2 - Broadcast on demand.
The broadcast will be issued when Network Neighborhood / NFS Network is selected. This will slow down response time, but will provide the most up-to-date LAN configuration and will eliminate unnecessary broadcasts.
SPTimeoutSeconds (Default: 15)
This is the network receive timeout value used when waiting for responses to the broadcast. Once a time period of the specified number of seconds has elapsed during which no responses have been received, the receive will terminate.
SPUpdateMinutes (Default: 5)
The number of minutes to wait before issuing the broadcast again. This value is only referenced if SPBrowseMethod is equal to 0.
Recommended Values: BrowseMethod: 0, SPBroadcastRetry: 0, SPTimeoutSeconds: 15, SPUpdateMinutes: 5 - or - SPBrowseMethod: 2, SPBroadcastRetry: 0, SPTimeoutSeconds: 1
All Contents © Copyright 1996, 1997, 1998