Pesquisa Imagens Maps Play YouTube Notícias Gmail Drive Mais »
Fazer login
Usuários de leitores de tela: para usar o modo de acessibilidade, é preciso clicar neste link. O modo de acessibilidade tem os mesmos recursos básicos, mas funciona melhor com seu leitor de tela.

Patentes

  1. Pesquisa avançada de patentes
Número da publicaçãoWO1999046672 A1
Tipo de publicaçãoRequerimento
Número do pedidoPCT/US1999/005197
Data de publicação16 set. 1999
Data de depósito10 mar. 1999
Data da prioridade10 mar. 1998
Número da publicaçãoPCT/1999/5197, PCT/US/1999/005197, PCT/US/1999/05197, PCT/US/99/005197, PCT/US/99/05197, PCT/US1999/005197, PCT/US1999/05197, PCT/US1999005197, PCT/US199905197, PCT/US99/005197, PCT/US99/05197, PCT/US99005197, PCT/US9905197, WO 1999/046672 A1, WO 1999046672 A1, WO 1999046672A1, WO 9946672 A1, WO 9946672A1, WO-A1-1999046672, WO-A1-9946672, WO1999/046672A1, WO1999046672 A1, WO1999046672A1, WO9946672 A1, WO9946672A1
InventoresAleksandr Ryabin, Aleksandr Pass
RequerenteFtp Software, Inc.
Exportar citaçãoBiBTeX, EndNote, RefMan
Links externos:  Patentscope, Espacenet
Direct network file system
WO 1999046672 A1
Resumo
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.
Reivindicações  (o texto de OCR pode conter erros)
- 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.
Descrição  (o texto de OCR pode conter erros)

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.

Citações de patente
Citada Data de depósito Data de publicação Requerente Título
US5745752 *13 dez. 199428 abr. 1998Microsoft CorporationDual namespace client having long and short filenames
US5764985 *27 jun. 19979 jun. 1998Microsoft CorpNotification mechanism for coordinating software extensions
US5806085 *1 maio 19968 set. 1998Sun 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
US5838907 *20 fev. 199617 nov. 1998Compaq Computer CorporationConfiguration manager for network devices and an associated method for providing configuration information thereto
US5838910 *14 mar. 199617 nov. 1998Domenikos; Steven D.Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5848410 *8 out. 19978 dez. 1998Hewlett Packard CompanySystem and method for selective and continuous index generation
Citada por
Citação Data de depósito Data de publicação Requerente Título
CN103135947A *26 mar. 20135 jun. 2013北京奇虎科技有限公司Method and device for displaying Windows disk letters
CN103135947B *26 mar. 20139 set. 2015北京奇虎科技有限公司一种显示Windows盘符的方法和装置
US7617222 *31 out. 200210 nov. 2009International Business Machines CorporationTransferring data and storing metadata across a network
Classificações
Classificação internacionalG06F17/30
Classificação cooperativaG06F17/30067
Classificação europeiaG06F17/30F
Eventos legais
DataCódigoEventoDescrição
16 set. 1999ALDesignated 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
16 set. 1999AKDesignated 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
17 nov. 1999121Ep: the epo has been informed by wipo that ep was designated in this application
9 dez. 1999DFPERequest for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
10 set. 2000NENPNon-entry into the national phase in:
Ref country code: KR
11 jan. 2001REGReference to national code
Ref country code: DE
Ref legal event code: 8642
27 jun. 2001122Ep: pct application non-entry in european phase