WO1999046672A1 - Direct network file system - Google Patents

Direct network file system Download PDF

Info

Publication number
WO1999046672A1
WO1999046672A1 PCT/US1999/005197 US9905197W WO9946672A1 WO 1999046672 A1 WO1999046672 A1 WO 1999046672A1 US 9905197 W US9905197 W US 9905197W WO 9946672 A1 WO9946672 A1 WO 9946672A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
operating system
windows
computer
drive letter
Prior art date
Application number
PCT/US1999/005197
Other languages
French (fr)
Inventor
Aleksandr Ryabin
Aleksandr Pass
Original Assignee
Ftp Software, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ftp Software, Inc. filed Critical Ftp Software, Inc.
Priority to AU29959/99A priority Critical patent/AU2995999A/en
Publication of WO1999046672A1 publication Critical patent/WO1999046672A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers

Definitions

  • the present invention relates to computer filesystems and, more specifically, to methods for accessing a particular filesystem from a client capable of accessing multiple filesystems.
  • a typical computer network includes components such as servers of various filesystem types, printers, and client workstations. Client applications gain access to filesystems over a network by using the components of an "installable filesystem.” Examples of installable filesystems are Microsoft's installable filesystem, Novell's NetWare installable filesystem, and InterDrive's NFS (Network File System) installable filesystem.
  • installable filesystems are Microsoft's installable filesystem, Novell's NetWare installable filesystem, and InterDrive's NFS (Network File System) installable filesystem.
  • a single client workstation may be configured to provide the user with access to multiple installable filesystems of different types. As shown in FIG.
  • NP Network provider
  • DLL Dynamic Link Library
  • Redirector a registered filesystem driver
  • a Microsoft network provider 22 and a Microsoft Redirector 28 provide the client workstation 10 with access to a Microsoft installable filesystem.
  • an InterDrive network provider 26 and an InterDrive Redirector 32 (installed as part of the InterDrive Client v4.0 (Atlas), manufactured by FTP Software, Inc. of Andover, Massachusetts), provide the client workstation 10 with access to an NFS installable filesystem.
  • Other network providers 24 and redirectors 30 in the memory 11 of the client workstation 10 provide the client workstation 10 with access to other installable filesystems.
  • An installable filesystem' s network provider allows the end user to interact with the installable filesystem.
  • the InterDrive NFS network provider 26 provides the ability to check or change properties of files on an NFS filesystem, and to list available servers and their contents.
  • User interaction with a network provider takes place through dialog boxes and other mechanisms provided by the operating system's graphical user interface (GUI) .
  • GUI graphical user interface
  • each installable filesystem accessible to the client workstation 10 is represented by a graphical icon in the File Manager (in Windows 3.1) or in Windows Explorer (in Windows 95/NT) . The user accesses the contents of a filesystem by double-clicking on its associated icon or by taking other appropriate action using the GUI.
  • Network providers 22, 24, and 26 differ from each other in various ways.
  • the Win32 operating subsystem 27 in Windows 95 and Windows NT provides a generic Application Program Interface (API) called WinNET 18, through which application programs, such as application program 16, in the memory 11 of the client workstation 10 interface with the network providers 22, 24, and 26.
  • API Application Program Interface
  • the WinNET API 18 interfaces with a Win32 component called a Multiple Provider Router (MPR) 20.
  • MPR Multiple Provider Router
  • the application 16 makes a filesystem request (for example, a request to map a drive) through the WinNET API 18, the request is forwarded to the MPR 20.
  • the MPR 20 in turn forwards the request to one of the network providers 22, 24, or 26. If, for example, the request is forwarded to the Microsoft network provider 22, then the Microsoft network provider 22 determines whether it is able to respond to the request, and sends a response to the MPR 20 representing the likelihood that it will be able to respond to the request.
  • the MPR 20 may then poll the remaining network providers 24, 26 in the same way.
  • the MPR 20 selects one of the polled network providers to service the request based on the response (s) received from the polled network providers. If, for example, the InterDrive network provider 26 responds with certainty that it is the correct network provider to service the request, then the MPR 20 selects the InterDrive network provider 26 to service the request. However, if none of the network providers 22, 24, or 26 responds with certainty that it is the correct network provider to service the request, the MPR 20 selects the network provider that responded with the most
  • the MPR 20 then sends the request to the selected network provider.
  • the selected network provider will service the request successfully.
  • the selected network provider may, however, be unable to service the request. In such a case, the network provider will return an error to the application 16 through the WinNet API 18.
  • Both the degree of responsiveness and the response to filesystem requests made by the application 16 depends - 4 - on the number of network providers, the order in which the network providers are polled by the MPR 20, and the behavior of each network provider. In many cases, a network provider must communicate with the corresponding network filesystem server to determine if it is the correct network provider to service the request. Thus, responsiveness and response to filesystem requests is also dependent upon the available network bandwidth and the response time of the network filesystems associated with the network providers.
  • the redirectors 28, 30, and 32 associated with each network filesystem interact similarly with the operating system 27 and with each other.
  • UNC Uniform Naming Convention
  • the request is sent through an operating system component called the Multiple UNC Provider (MUP) 34.
  • MUP 34 polls each of the redirectors 28, 30, and 32 to select a redirector to use to service the request.
  • IFSMgr Installable Filesystem Manager
  • a redirector' s main responsibility is to open, read from, and write to network filesystem files and directories.
  • the response and responsiveness of filesystem requests handled by the redirectors 28, 30, and 32 depends on the number of network providers, the order in which the network providers are polled by the MUP (or IFSMgr) , the behavior of each network provider, the available network bandwidth, and the response time of the network filesystems associated with the network providers.
  • the invention features a computer- implemented method, in a system including a computer running a 32 -bit Microsoft Windows operating system, for forwarding filesystem requests to a network component .
  • An identifier is obtained from a user, and requests identified by the identifier are directly forwarded to the network component.
  • the operating system may be Windows 95 or Windows NT.
  • the identifier may be a drive letter.
  • the network component may be a redirector.
  • Information describing an association between the identifier and the network component may be stored in the Windows Registry.
  • the information may be a network provider name, a network provider type, and a path name.
  • Associating a drive letter with a set of network components allows applications to bypass the MPR and MUP's polling mechanisms so that filesystem requests are sent directly to the network components. This eliminates the possibility that a filesystem request will be directed to an incorrect network component, and can result in increased responsiveness to filesystem requests.
  • Associating a drive letter with a set of network components makes it possible to reference all of the network servers (and their filesystems) associated with the network components through the drive letter, without explicitly mapping each of the servers and filesystems to its own drive letter. This both reduces the number of drive letters needed to directly access multiple servers, and simplifies access to multiple servers by providing a single point of access to them.
  • Another advantage of the invention is that it provides applications which are not capable of generating filesystem requests using UNC paths with the ability to reference network components through a drive letter rather than through a UNC path. In this way, existing applications need not be modified to realize the benefits of the invention.
  • FIG. 1 is a block diagram of software components within a client workstation and their interactions with each other.
  • FIG. 2 is a flow chart of a method for mapping a drive letter and a UNC path to network components.
  • FIG. 3 is a block diagram of software components within a client workstation after a drive letter and UNC path have been mapped to network components.
  • FIG. 4 is a diagram of a graphical user interface window displaying the exports of a server.
  • the user can send NFS filesystem requests directly to the InterDrive network components 26 and 32, thereby bypassing the MPR and the MUP.
  • Such direct requests can be made either by: (1) using a special Uniform Naming Convention (UNC) path, or (2) mapping the special UNC path to a logical drive, referred to as a "Direct NFS Device, " identified by a drive letter.
  • the Direct NFS Device is implemented as a feature added to the InterDrive Client v4.0. - 7 -
  • the user creates a mapping between a drive letter and the InterDrive network components 26 and 32 using Microsoft Windows Explorer as follows.
  • the user double-clicks the "Network Neighborhood” icon on the desktop (step 40) , and then double-clicks on the "Entire Network” icon in the window that appears (step 42) .
  • the file selection dialog box contains a drive box, which lists available drive letters. The user clicks on an available drive letter (step 48) .
  • the file selection dialog box also contains a path box which contains the UNC path " ⁇ $InterDrive ⁇ $Net" . This is a special UNC path identifying the InterDrive network components 26 and 32.
  • the user presses "Enter” or clicks on the file selection dialog box "OK” button (step 52) .
  • the selected drive letter and special UNC path are then mapped to the InterDrive network components 26 and 32 (step 54) .
  • the MPR sends an NPAddConnection () command to the InterDrive Network Provider 26, with the selected drive letter and the special UNC path as parameters.
  • the InterDrive Network Provider 26 sends a request to the InterDrive redirector 32 to create a connection between the selected drive letter and the InterDrive network components 26, 32.
  • the InterDrive redirector 32 internally associates the selected drive letter and the special UNC path with the connection. Furthermore, if the user indicates that this is to be a permanent connection, the MPR records the provider name ("InterDrive NT"), the provider type (a number which uniquely identifies the InterDrive Network Provider 26), and the remote path ( " ⁇ $InterDrive ⁇ $Net " ) in the Windows Registry.
  • subsequent filesystem requests addressed to the Direct NFS Device are forwarded by the Win32 subsystem 27 to the IFSMgr component in Win95 or to the NTOSKNRL (NT Operating System Kernel) in WinNT 36, which forwards the filesystem request directly to the InterDrive redirector 32.
  • the user may map a drive letter to the InterDrive network components 26 and 32 in a DOS session, using the InterDrive Client Idmount command, as follows :
  • Idmount e ⁇ $InterDrive ⁇ $Net or by using the following command: net use e : ⁇ $Interdrive ⁇ $Net where e : is the drive letter to map to the InterDrive network components 26 and 32. Use of either of these commands results in the InterDrive redirector 32 being called to create a connection between the selected drive letter and the InterDrive network components 26, 32, as described above with respect to step 54 (FIG. 2) .
  • the "exports" of a server are symbolic names of volumes which the server advertises as being mountable (that is, available for mapping) by a client. After an export is mounted (mapped) by a client to a drive letter, the root directory of the mapped drive points to the export. Referring to FIG. 4, for example, if the drive letter "I:" has been mapped to the InterDrive Client network components 26 and 32, then a user can see the exports of a server 'serverl' through Microsoft Windows Explorer as follows. The Direct NFS Device representing the InterDrive network components 26 and 32 is represented in the Windows Explorer window by the drive letter "I:".
  • the user can view the exports of a server by (1) expanding drive I:, (2) expanding "NFS Servers I Have Configured", and (3) expanding "serverl”.
  • the user can perform the same function in a DOS session by typing "dir
  • the Direct NFS Device can also be accessed through its UNC path ( ⁇ $InterDrive ⁇ $Net) .
  • UNC path ⁇ $InterDrive ⁇ $Net
  • UFS User Data Management
  • a UNC path allows the user to avoid allocating a drive letter to the Direct NFS Device. From a DOS session, to see a list of servers in InterDrive' s "NFS Servers I Have Configured" domain, a user can type: "dir ⁇ $InterDrive ⁇ $Net ⁇ $myservs" , where $myservs is a short name for "NFS Servers I Have Configured.” This operation allows a user to "browse" a server from the command line. - 10 -

Abstract

File system (34) requests are forwarded to network components on a computer running a 32-bit windows (27) operating system by obtaining an identifier from a user and directly forwarding requests identified by the identifier to the network components.

Description

DIRECT NETWORK FILE SYSTEM
Background of the Invention The present invention relates to computer filesystems and, more specifically, to methods for accessing a particular filesystem from a client capable of accessing multiple filesystems.
A typical computer network includes components such as servers of various filesystem types, printers, and client workstations. Client applications gain access to filesystems over a network by using the components of an "installable filesystem." Examples of installable filesystems are Microsoft's installable filesystem, Novell's NetWare installable filesystem, and InterDrive's NFS (Network File System) installable filesystem. A single client workstation may be configured to provide the user with access to multiple installable filesystems of different types. As shown in FIG. 1, in a memory 11 of a client workstation 10 running one of the Microsoft Windows operating systems (for example, Windows 95 or Windows NT) , associated with each installable filesystem accessible to the client workstation 10 are two pieces of software collectively referred to as "network components" : (1) the "network provider" (NP) , which runs as a registered Dynamic Link Library (DLL) in user space, and (2) a registered filesystem driver (also known as a "redirector") which runs in kernel space. (User-level applications run in user space in Windows NT and in Ring
3 in Windows 95, and are restricted from using certain instructions which are reserved for programs running in kernel space in Windows NT and in Ring 0 in Windows 95. ) For example, a Microsoft network provider 22 and a Microsoft Redirector 28 provide the client workstation 10 with access to a Microsoft installable filesystem. Similarly, an InterDrive network provider 26 and an InterDrive Redirector 32 (installed as part of the InterDrive Client v4.0 (Atlas), manufactured by FTP Software, Inc. of Andover, Massachusetts), provide the client workstation 10 with access to an NFS installable filesystem. Other network providers 24 and redirectors 30 in the memory 11 of the client workstation 10 provide the client workstation 10 with access to other installable filesystems.
An installable filesystem' s network provider allows the end user to interact with the installable filesystem. For example, the InterDrive NFS network provider 26 provides the ability to check or change properties of files on an NFS filesystem, and to list available servers and their contents. User interaction with a network provider takes place through dialog boxes and other mechanisms provided by the operating system's graphical user interface (GUI) . For example, each installable filesystem accessible to the client workstation 10 is represented by a graphical icon in the File Manager (in Windows 3.1) or in Windows Explorer (in Windows 95/NT) . The user accesses the contents of a filesystem by double-clicking on its associated icon or by taking other appropriate action using the GUI.
Network providers 22, 24, and 26 differ from each other in various ways. To allow application programs to communicate with different network providers (and the filesystems they represent) in a standard way, the Win32 operating subsystem 27 in Windows 95 and Windows NT provides a generic Application Program Interface (API) called WinNET 18, through which application programs, such as application program 16, in the memory 11 of the client workstation 10 interface with the network providers 22, 24, and 26. - 3 -
The WinNET API 18 interfaces with a Win32 component called a Multiple Provider Router (MPR) 20. When the application 16 makes a filesystem request (for example, a request to map a drive) through the WinNET API 18, the request is forwarded to the MPR 20. The MPR 20 in turn forwards the request to one of the network providers 22, 24, or 26. If, for example, the request is forwarded to the Microsoft network provider 22, then the Microsoft network provider 22 determines whether it is able to respond to the request, and sends a response to the MPR 20 representing the likelihood that it will be able to respond to the request. The MPR 20 may then poll the remaining network providers 24, 26 in the same way.
After polling one or more of the network providers 22, 24, and 26, the MPR 20 selects one of the polled network providers to service the request based on the response (s) received from the polled network providers. If, for example, the InterDrive network provider 26 responds with certainty that it is the correct network provider to service the request, then the MPR 20 selects the InterDrive network provider 26 to service the request. However, if none of the network providers 22, 24, or 26 responds with certainty that it is the correct network provider to service the request, the MPR 20 selects the network provider that responded with the most
"positive" response to service the request.
The MPR 20 then sends the request to the selected network provider. Typically, the selected network provider will service the request successfully. The selected network provider may, however, be unable to service the request. In such a case, the network provider will return an error to the application 16 through the WinNet API 18.
Both the degree of responsiveness and the response to filesystem requests made by the application 16 depends - 4 - on the number of network providers, the order in which the network providers are polled by the MPR 20, and the behavior of each network provider. In many cases, a network provider must communicate with the corresponding network filesystem server to determine if it is the correct network provider to service the request. Thus, responsiveness and response to filesystem requests is also dependent upon the available network bandwidth and the response time of the network filesystems associated with the network providers.
The redirectors 28, 30, and 32 associated with each network filesystem interact similarly with the operating system 27 and with each other. When a filesystem request is made by the application 16 using a Uniform Naming Convention (UNC) path, for example, open ( "\\myserver\mydir\myfile" ) , the request is sent through an operating system component called the Multiple UNC Provider (MUP) 34. The MUP 34 polls each of the redirectors 28, 30, and 32 to select a redirector to use to service the request. On Windows 95, the functionality of the MUP is provided by the Installable Filesystem Manager (IFSMgr) .
A redirector' s main responsibility is to open, read from, and write to network filesystem files and directories. As with network providers, the response and responsiveness of filesystem requests handled by the redirectors 28, 30, and 32 depends on the number of network providers, the order in which the network providers are polled by the MUP (or IFSMgr) , the behavior of each network provider, the available network bandwidth, and the response time of the network filesystems associated with the network providers.
Summary of the Invention - 5 -
In one aspect, the invention features a computer- implemented method, in a system including a computer running a 32 -bit Microsoft Windows operating system, for forwarding filesystem requests to a network component . An identifier is obtained from a user, and requests identified by the identifier are directly forwarded to the network component. The operating system may be Windows 95 or Windows NT. The identifier may be a drive letter. The network component may be a redirector. Information describing an association between the identifier and the network component may be stored in the Windows Registry. The information may be a network provider name, a network provider type, and a path name. Among the advantages of the invention are one or more of the following.
Associating a drive letter with a set of network components (that is, a network provider and a redirector) allows applications to bypass the MPR and MUP's polling mechanisms so that filesystem requests are sent directly to the network components. This eliminates the possibility that a filesystem request will be directed to an incorrect network component, and can result in increased responsiveness to filesystem requests.
Associating a drive letter with a set of network components (that is, a network provider and a redirector) makes it possible to reference all of the network servers (and their filesystems) associated with the network components through the drive letter, without explicitly mapping each of the servers and filesystems to its own drive letter. This both reduces the number of drive letters needed to directly access multiple servers, and simplifies access to multiple servers by providing a single point of access to them.
Another advantage of the invention is that it provides applications which are not capable of generating filesystem requests using UNC paths with the ability to reference network components through a drive letter rather than through a UNC path. In this way, existing applications need not be modified to realize the benefits of the invention.
Other features and advantages of the invention will become apparent from the following description and from the claims.
Brief Description of the Drawings FIG. 1 is a block diagram of software components within a client workstation and their interactions with each other.
FIG. 2 is a flow chart of a method for mapping a drive letter and a UNC path to network components. FIG. 3 is a block diagram of software components within a client workstation after a drive letter and UNC path have been mapped to network components.
FIG. 4 is a diagram of a graphical user interface window displaying the exports of a server.
Detailed Description
By using the InterDrive redirector 32 to map a drive letter to the InterDrive network provider 26 and the InterDrive redirector 32 (referred to collectively as the InterDrive "network components"), the user can send NFS filesystem requests directly to the InterDrive network components 26 and 32, thereby bypassing the MPR and the MUP. Such direct requests can be made either by: (1) using a special Uniform Naming Convention (UNC) path, or (2) mapping the special UNC path to a logical drive, referred to as a "Direct NFS Device, " identified by a drive letter. The Direct NFS Device is implemented as a feature added to the InterDrive Client v4.0. - 7 -
Referring to FIG. 2, the user creates a mapping between a drive letter and the InterDrive network components 26 and 32 using Microsoft Windows Explorer as follows. The user double-clicks the "Network Neighborhood" icon on the desktop (step 40) , and then double-clicks on the "Entire Network" icon in the window that appears (step 42) . The user clicks the right mouse button on the InterDrive icon in the window that appears (step 44) , and selects the "Map Direct NFS Drive" menu selection from the menu that then appears (step 46) .
This causes a file selection dialog box to appear. The file selection dialog box contains a drive box, which lists available drive letters. The user clicks on an available drive letter (step 48) . The file selection dialog box also contains a path box which contains the UNC path "\\$InterDrive\$Net" . This is a special UNC path identifying the InterDrive network components 26 and 32.
After selecting a drive letter, the user presses "Enter" or clicks on the file selection dialog box "OK" button (step 52) . The selected drive letter and special UNC path are then mapped to the InterDrive network components 26 and 32 (step 54) . Specifically, the MPR sends an NPAddConnection () command to the InterDrive Network Provider 26, with the selected drive letter and the special UNC path as parameters. The InterDrive Network Provider 26 sends a request to the InterDrive redirector 32 to create a connection between the selected drive letter and the InterDrive network components 26, 32.
If the connection is successfully created, the InterDrive redirector 32 internally associates the selected drive letter and the special UNC path with the connection. Furthermore, if the user indicates that this is to be a permanent connection, the MPR records the provider name ("InterDrive NT"), the provider type (a number which uniquely identifies the InterDrive Network Provider 26), and the remote path ( " \\$InterDrive\$Net " ) in the Windows Registry. Referring to FIG. 3, subsequent filesystem requests addressed to the Direct NFS Device (that is, requests using the selected drive letter) are forwarded by the Win32 subsystem 27 to the IFSMgr component in Win95 or to the NTOSKNRL (NT Operating System Kernel) in WinNT 36, which forwards the filesystem request directly to the InterDrive redirector 32. This eliminates the possibility that any other installable filesystem components will erroneously attempt to service the request . Alternatively, the user may map a drive letter to the InterDrive network components 26 and 32 in a DOS session, using the InterDrive Client Idmount command, as follows :
Idmount e : \\$InterDrive\$Net or by using the following command: net use e : \\$Interdrive\$Net where e : is the drive letter to map to the InterDrive network components 26 and 32. Use of either of these commands results in the InterDrive redirector 32 being called to create a connection between the selected drive letter and the InterDrive network components 26, 32, as described above with respect to step 54 (FIG. 2) .
The "exports" of a server are symbolic names of volumes which the server advertises as being mountable (that is, available for mapping) by a client. After an export is mounted (mapped) by a client to a drive letter, the root directory of the mapped drive points to the export. Referring to FIG. 4, for example, if the drive letter "I:" has been mapped to the InterDrive Client network components 26 and 32, then a user can see the exports of a server 'serverl' through Microsoft Windows Explorer as follows. The Direct NFS Device representing the InterDrive network components 26 and 32 is represented in the Windows Explorer window by the drive letter "I:". Expanding the listing for the drive letter "I:" reveals an "NFS Servers I Have Configured" folder and an "NFS Servers On My Subnet" folder. These folders contain servers that match the server entries in the InterDrive "NFS Servers I Have Configured" domain and the "NFS Servers on My Subnet" domain as seen through the Microsoft Windows "Network Neighborhood." As the user adds and removes servers from the InterDrive groups (that is, "NFS Servers I Have Configured" and "NFS Servers on My Subnet"), the InterDrive Client automatically updates the drive folders listed under the drive letter "I:".
Referring again to FIG. 4, the user can view the exports of a server by (1) expanding drive I:, (2) expanding "NFS Servers I Have Configured", and (3) expanding "serverl". The user can perform the same function in a DOS session by typing "dir
I : \$myservs\serverl" , where $myservs is a short name for "NFS Servers I Have Configured." Alternatively, the user could type "dir I:\serverl".
The Direct NFS Device can also be accessed through its UNC path (\\$InterDrive\$Net) . Although using the special UNC path to reference the Direct NFS Device may not be as convenient as using a drive letter, using a UNC path allows the user to avoid allocating a drive letter to the Direct NFS Device. From a DOS session, to see a list of servers in InterDrive' s "NFS Servers I Have Configured" domain, a user can type: "dir \\$InterDrive\$Net\$myservs" , where $myservs is a short name for "NFS Servers I Have Configured." This operation allows a user to "browse" a server from the command line. - 10 -
Although elements of the invention are described in terms of a software implementation, the invention may be implemented in software or hardware or firmware, or a combination of the three.
The present invention has been described in terms of an embodiment. The invention, however, is not limited to the embodiment depicted and described. Rather, the scope of the invention is defined by the claims.

Claims

- 11 - What is claimed is:
1. In a system comprising a computer running a 32 -bit Microsoft Windows operating system, a computer- implemented method for forwarding filesystem requests to a network component, the method comprising: obtaining an identifier from a user; and directly forwarding requests identified by the identifier to the network component.
2. The method of claim 1, wherein the operating system comprises a Windows 95 operating system.
3. The method of claim 1, wherein the operating system comprises a Windows NT operating system.
4. The method of claim 1, wherein the identifier comprises a drive letter.
5. The method of claim 1, wherein the network component comprises a redirector.
6. The method of claim 1, further comprising: storing information describing an association between the identifier and the network component in a computer-readable medium.
7. The method of claim 6, wherein the information comprises a network provider name, a network provider type , and a path name .
8. The method of claim 7, wherein the storing step comprises storing the information in the Windows
Registry. - 12 -
9. In a system comprising a computer running a 32 -bit Microsoft Windows operating system, a computer- implemented method for forwarding filesystem requests to a redirector, the method comprising: obtaining a drive letter from a user; storing a network provider name, a network provider type, and a path name describing an association between the drive letter and the redirector in a Windows Registry; and directly forwarding requests identified by the drive letter to the redirector.
10. A computer program tangibly stored on a computer- readable medium and operable to cause a computer running a 32 -bit Microsoft Windows operating system to forward filesystem requests to a network component, comprising instructions to: obtain an identifier from a user; and directly forward requests identified by the identifier to the network component.
11. The computer program of claim 10, wherein the operating system comprises a Windows 95 operating system.
12. The computer program of claim 10, wherein the operating system comprises a Windows NT operating system.
13. The computer program of claim 10, wherein the identifier comprises a drive letter.
14. The computer program of claim 10, wherein the network component comprises a redirector.
15. The computer program of claim 10, further comprising instructions to: - 13 - store information describing an association between the identifier and the network component in a computer-readable medium.
16. The computer program of claim 15, wherein the information comprises a network provider name, a network provider type, and a path name.
17. The computer program of claim 16, wherein instructions to store the information comprise instructions to store the information in the Windows Registry.
18. A computer program tangibly stored on a computer- readable medium and operable to cause a computer running a 32 -bit Microsoft Windows operating system to forward filesystem requests to a network component, comprising instructions to: obtain a drive letter from a user; store a network provider name, a network provider type, and a path name describing an association between the drive letter and the redirector in a Windows Registry; and directly forward requests identified by the drive letter to the redirector.
PCT/US1999/005197 1998-03-10 1999-03-10 Direct network file system WO1999046672A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU29959/99A AU2995999A (en) 1998-03-10 1999-03-10 Direct network file system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US3826398A 1998-03-10 1998-03-10
US09/038,263 1998-03-10

Publications (1)

Publication Number Publication Date
WO1999046672A1 true WO1999046672A1 (en) 1999-09-16

Family

ID=21898940

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/005197 WO1999046672A1 (en) 1998-03-10 1999-03-10 Direct network file system

Country Status (2)

Country Link
AU (1) AU2995999A (en)
WO (1) WO1999046672A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7617222B2 (en) * 2002-06-26 2009-11-10 International Business Machines Corporation Transferring data and storing metadata across a network
CN103135947A (en) * 2013-03-26 2013-06-05 北京奇虎科技有限公司 Method and device for displaying Windows disk letters

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5745752A (en) * 1994-12-13 1998-04-28 Microsoft Corporation Dual namespace client having long and short filenames
US5764985A (en) * 1994-12-13 1998-06-09 Microsoft Corp Notification mechanism for coordinating software extensions
US5806085A (en) * 1996-05-01 1998-09-08 Sun Microsystems, Inc. Method for non-volatile caching of network and CD-ROM file accesses using a cache directory, pointers, file name conversion, a local hard disk, and separate small database
US5838907A (en) * 1996-02-20 1998-11-17 Compaq Computer Corporation Configuration manager for network devices and an associated method for providing configuration information thereto
US5838910A (en) * 1996-03-14 1998-11-17 Domenikos; Steven D. Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5848410A (en) * 1997-10-08 1998-12-08 Hewlett Packard Company System and method for selective and continuous index generation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5745752A (en) * 1994-12-13 1998-04-28 Microsoft Corporation Dual namespace client having long and short filenames
US5764985A (en) * 1994-12-13 1998-06-09 Microsoft Corp Notification mechanism for coordinating software extensions
US5838907A (en) * 1996-02-20 1998-11-17 Compaq Computer Corporation Configuration manager for network devices and an associated method for providing configuration information thereto
US5838910A (en) * 1996-03-14 1998-11-17 Domenikos; Steven D. Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5806085A (en) * 1996-05-01 1998-09-08 Sun Microsystems, Inc. Method for non-volatile caching of network and CD-ROM file accesses using a cache directory, pointers, file name conversion, a local hard disk, and separate small database
US5848410A (en) * 1997-10-08 1998-12-08 Hewlett Packard Company System and method for selective and continuous index generation

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7617222B2 (en) * 2002-06-26 2009-11-10 International Business Machines Corporation Transferring data and storing metadata across a network
CN103135947A (en) * 2013-03-26 2013-06-05 北京奇虎科技有限公司 Method and device for displaying Windows disk letters
CN103135947B (en) * 2013-03-26 2015-09-09 北京奇虎科技有限公司 A kind of method and apparatus showing Windows drive

Also Published As

Publication number Publication date
AU2995999A (en) 1999-09-27

Similar Documents

Publication Publication Date Title
US6256031B1 (en) Integration of physical and virtual namespace
US7676564B2 (en) Managing stored data on a computer network
US9021079B2 (en) Domain name service server
US7827317B2 (en) Apparatus for management of mixed protocol storage networks
US5708832A (en) Network redirection for the enhancement of server capacities
JP4647096B2 (en) Method and system for configuring a computer to connect to a network using a network connection object
US20040010563A1 (en) Method for enterprise device naming for storage devices
US20090013065A1 (en) Information processing apparatus, information processing apparatus control method, and storage medium storing computer program
US8347284B2 (en) Method and system for creation of operating system partition table
US8060891B2 (en) Management of external hardware appliances in a distributed operating system
US8151360B1 (en) System and method for administering security in a logical namespace of a storage system environment
US7293030B2 (en) Methods, functional data, and systems to represent a storage environment
US20120047170A1 (en) Techniques for accessing remote files
WO1999046672A1 (en) Direct network file system
US7945643B2 (en) Rules for shared entities of a network-attached storage device
Cisco Network Wizard
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Release Notes for Network Registrar 5.0
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus
Cisco Using the NBUTIL Utility with CiscoRemote Plus

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase