DiskAccess 95- Frequently
Asked Support Questions

  • Why can't I mount some NFS shares (exports) from the command line?
  • I still can't mount an NFS share!
  • I made a new NFS share on a server that also supports LAN Manager and cannot access it.
  • I have enabled locking on all of my clients, but when I try to access a file with two different clients, I get no warnings or errors. How can this be?
  • I have enabled locking on my client, and now it runs very slowly.
  • My server is running UNIX™, and I have two files with the same name, but the letters are different case(s). When I list the files in that directory using Explorer, I see both of the filenames as they exist on the server. But when I list the same directory using File Manager, one of the filenames has been changed (has some tildes (~) and possibly a number in it).
  • My server is running UNIX™, and I have two subdirectories under the mount point with the same name, but the letters in each have different case(s). When I get a directory listing of the mount point, I can see both of these directories, but when I do a directory list of these directories, I get the same listing for both directories. Why can't I get the correct listing for each?
  • I am unable to access or save files from certain applications when Case Preserve is selected in the DiskAccess configuration menu.
  • The file/directory name, which I created appears to be truncated when I get a directory listing. What happened?
  • How does DiskAccess obtain the list of NFS servers displayed when the user clicks on NFS Network from Network Neighborhood?
  • Can DiskAccess be configured to browse NFS servers on remote LANs? Can the scope of a browse of the NFS Network be limited to a specific LAN?
  • How do I configure the DiskAccess network browse broadcast parameters?

  • Why can't I mount some NFS shares (exports) from the command line?

    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).

  • I still can't mount an NFS share!

    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.


    Go To Top

  • I made a new NFS share on a server that also supports LAN Manager and cannot access it.

    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.

  • I have enabled locking on all of my clients, but when I try to access a file with two different clients, I get no warnings or errors. How can this be?

    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.


    Go To Top

  • I have enabled locking on my client and now it runs very slowly.

    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.

  • My server is running UNIX™, and I have two files with the same name, but the letters are different case(s). When I list the files in that directory using Explorer, I see both filenames as they exist on the server. But when I list the same directory using File Manager, one of the filenames has been changed (has some tildes (~) and possibly a number in it).

    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.


    Go To Top

  • My server is running UNIX™, and I have two subdirectories under the mount point with the same name, but the letters in each have different case(s). When I get a directory listing of the mount point, I can see both of these directories, but when I do a directory list of these directories, I get the same listing for both directories. Why can't I get the correct listing for each?

    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.


    Go To Top

  • I am unable to access or save files from certain applications when "Case Preserve" is selected in the DiskAccess configuration menu.

    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.

  • The file/directory name, which I created appears to be truncated when I get a directory listing. What happened?

    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.


    Go To Top

  • How does DiskAccess obtain the list of NFS servers displayed when the user clicks on NFS Network from Network Neighborhood?

    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.


    Go To Top

  • Can DiskAccess be configured to browse NFS servers on remote LANs? Can the scope of a browse of the NFS Network be limited to a specific LAN?

    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 129.135.102.255 instead of 255.255.255.255 will limit the broadcast to the 129.135.102 LAN.

  • How do I configure the DiskAccess network browse broadcast parameters?

    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.


    Go To Top

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DANP\NetworkProvider

    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 129.135.102.255 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.


    Go To Top

    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


    Go To Top

    All Contents © Copyright 1996, 1997, 1998
    Intergraph Corporation