US20090282046A1 - Techniques for accessing remote files - Google Patents

Techniques for accessing remote files Download PDF

Info

Publication number
US20090282046A1
US20090282046A1 US12/115,652 US11565208A US2009282046A1 US 20090282046 A1 US20090282046 A1 US 20090282046A1 US 11565208 A US11565208 A US 11565208A US 2009282046 A1 US2009282046 A1 US 2009282046A1
Authority
US
United States
Prior art keywords
file system
file
local
remote
junction
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US12/115,652
Inventor
Scott Alan Isaacson
Nithya Balachandran
R. Shyamsundar
Haripriya Srinivasaraghavan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oracle International Corp
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US12/115,652 priority Critical patent/US20090282046A1/en
Assigned to NOVELL, INC. reassignment NOVELL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BALACHANDRAN, NITHYA, SHYAMSUNDAR, R., SRINIVASARAGHAVAN, HARIPRIYA, ISAACSON, SCOTT ALAN
Publication of US20090282046A1 publication Critical patent/US20090282046A1/en
Priority to US13/284,018 priority patent/US8171066B2/en
Assigned to CPTN HOLDINGS LLC reassignment CPTN HOLDINGS LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: NOVELL, INC.
Assigned to ORACLE INTERNATIONAL CORPORATION reassignment ORACLE INTERNATIONAL CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CPTN HOLDINGS LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems

Definitions

  • OS operating systems
  • the remote file system might be another partition on the local disk or it might be a remote file system that is accessed by a protocol such as Netware Core Protocol (NCP), Server Message Block Protocol (SMB)/Common Internet File System Protocol (CIFS), or Network File System Protocol (NFS).
  • NCP Netware Core Protocol
  • SMB Server Message Block Protocol
  • CIFS Common Internet File System Protocol
  • NFS Network File System Protocol
  • Any remotely mounted file system adds significant value and works well when there are no changes in disk hardware or servers that support the remote file systems; however, when there are changes, the amount and scope of the reconfiguration management steps are significant and grow exponentially with the number of nodes and mount points needed.
  • the mount point on server A includes the identity of server B as well a some sort of location information for B, called “Loc(B).” If Loc(B) ever changes, then the mount point has to be updated. Take for example, if Loc(B) is the IP Address of B and B's address is changed, the mount point on A must be updated. If Loc(B) is the Domain Name Service (DNS) name of B, then B can change its address because the DNS server will then serve up the new address of B and in this case the mount point on A need not be updated. If the location of the file system on B moves, then the mount point on A must be updated. If the file system itself moves from B to C, then the mount point on A must be updated. So, in many cases, if the data on or the location of or even the identity of B ever changes, then the mount points on A must be updated.
  • DNS Domain Name Service
  • a distributed file system is a better way to access data from a remote server by using junctions rather than mount points.
  • a junction is a file, which includes a globally unique identifier (GUID) that identifies the location of a storage volume housing the data associated with the junction.
  • GUID globally unique identifier
  • the GUID's mapping to a specific volume for the data is referenced as an entry in a database. If the final location of the data ever changes, no junctions on file systems need to be updated, only the single entry for that GUID in the database needs to be updated.
  • GUID globally unique identifier
  • the client will look up the junction file obtain the GUID and look in the database and then find out where the file system is located that hosts the volume of that file and then will “follow” that link to the server that has the data.
  • junctions are generally believed to be better than mount points for several reasons. 1) The data from B never has to flow through A in order to reach C. If C needs files that are on A, C talks directly to A. If C finds that files are on B, it will talk directly to B. 2) The junctions are indirect in that the actual location of the data for a junction is stored in the database (via a GUID) rather than on the file system for A. If changes are made to B or where the data is stored on B, only the data in the database needs to be changed (the mapping to the GUID); no changes are needed for any of the junctions on the file system on A.
  • junction resolution will continue to work even if a volume is moved between servers. This can be done using a volume manager move and split operations. If the entire server is moved to a different server, the data on the original target server will need to be moved using the volume manager operations to make sure database will be updated correctly. (Currently move/split operations require source and target volumes to be within the same processing management context.)
  • a distribute file system adds much value to conventional remote mounting approaches, but one potentially limiting drawback of junctions is that there is client software that is needed on each client to correctly process the junction and to talk to the database.
  • client software that is needed on each client to correctly process the junction and to talk to the database.
  • each of the clients in a distribute file system approach has to be aware of and have software to handle junctions. This creates a support issue for an enterprise, similar to the remote mount discussion presented above.
  • a method for accessing a remote file is presented.
  • a request is received for accessing a file from a client.
  • the request is received at a local file system, which processes on a server and which supports the client and multiple additional clients associated with a local processing environment.
  • a path is resolved to the file across a network as a junction.
  • the junction is used for looking up a remote file system over the network that has the file and that is accessible via the path.
  • the remote file system is contacted over the network with the request for access to the file.
  • results associated with the request are acquired to access the file from the remote file system and the results are delivered to the client.
  • FIG. 1 is a diagram of a method for accessing a remote file, according to an example embodiment.
  • FIG. 2 is a diagram of a method for managing access to remote files, according to an example embodiment.
  • FIG. 3 is a diagram of remote file access system, according to an example embodiment.
  • FIG. 4 is a diagram of another remote file access system, according to an example embodiment.
  • a “resource” includes a user, content, a processing device, a node, a service, an application, a system, a gateway, a directory, a data store, a World-Wide Web (WWW) site, an end-user, groups of users, combinations of these things, etc.
  • the terms “service,” “module,” “software,” and “application” may be used interchangeably herein and refer to a type of software resource that includes instructions, which when executed by a machine performs operations that change the state of the machine and that may produce output.
  • a “client” or “client workstation” is machine (computer, processing device, etc.) that a user uses to access a network.
  • the client includes a processing environment.
  • clients may be used interchangeably and synonymously.
  • a “server” is a machine that the client interacts with over a network, such as the Internet.
  • the user via its client, attempts to establish a connection with the server or to a resource of the server.
  • Various embodiments of this invention can be implemented in existing network architectures, file systems, browsers, proxies, agents, storage systems, security systems, data centers, and/or communication devices.
  • the techniques presented herein are implemented in whole or in part in the Novell® network, proxy server products, email products, operating system products, data center products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.
  • FIG. 1 is a diagram of a method 100 for accessing a remote file, according to an example embodiment.
  • the method 100 (herein after “local file system service”) is implemented as instructions (within a computer-readable storage medium) that process on a server machine (server) over a network and is accessed client machines (clients) of the server.
  • the network may be wired, wireless, or a combination of wired and wireless.
  • the local file system service receives a request to access a file from a client.
  • a user or automated application makes the request for access via a client.
  • the request is received and processed at a local file system.
  • the local file system processes on the server and supports multiple additional clients and their users/applications, which are associated with a local processing environment.
  • clients via users or automated applications make requests for files that are processed by the local file system at the server and in some cases handled by the local file system service.
  • the local file system service handles requests when any file being requested is associated with a remote file system that is remote from the local processing environment over the network, such as over the Internet.
  • the local file system service resolves a path to the file across a network as a junction. That is, the path or identifier supplied with the request for access to the file is used to identify that the file being requested is in a remote processing environment from the local file system service and is being managed by a remote file system.
  • the junction provides the ability to resolve the path to a network specific location.
  • the junction is itself a file that includes a GUID for a specific volume of the file being requested, the GUID is mapped to a specific path on the remote file system, such as via a mapping within a database.
  • the local file system service maintains the junction and other junctions, which are associated with other remote file systems and other remote processing environments within a volume lookup database. That is, the GUID's for remote volumes of remote files and their corresponding mappings are retained in the volume lookup database. This is done instead of maintaining and managing mount points for the remote file system and any other remote file systems. Keeping GUID mappings for volumes of files associated with junctions within a volume lookup database allows for easier maintenance and permits changes to be made to locations of remote file systems and files, such that the dependent clients can each effectuate the changes via a single update to the volume lookup database entry.
  • the actual volume lookup database can reside locally to the local file system service or can be accessed remotely on a remote server by the local file system service.
  • each client includes software to handle and manage DFS junction lookup and usage, this means any changes in this software has to be updated to all the clients.
  • DFS Distribute File Service
  • the local file system service is enabled for searching the volume database with an identifier for the file being requested.
  • the file identifier is supplied with the original request, which was received from the client.
  • the volume database returns a mapping for the DFS junction (a file that includes a GUID for a remote volume where the file identifier can be found).
  • the local file system service processes the local file system as a flexible user space file system (FUSE).
  • the FUSE looks for and discovers the junction when needed.
  • the local file system service recognizes the junction as a DFS junction.
  • the requests may be for files that are not associated with a remote file system.
  • normal local file system processing can be used as there is no need for any junction resolution in those cases.
  • the local file system service recognizes and assists in processing in the manners discussed herein and above when the file access requests are for files that are remote from the local processing environment and remote from the local file system.
  • the local file system service looks up the junction (via a junction file to obtain a GUID for the desired volume of the file—the GUID is then mapped to the remote file system via the path) to find a remote file system over the network that has the file and that is accessible via the path.
  • the local file system service contacts the remote file system over the network with the request for access to the file. So, the local file system service rather than the client directly interacts with the remote file system that houses the file identified by the junction resolution and the path.
  • the local file system service uses a different protocol from that which was used by the client to make the request to the local file system.
  • the communication protocol used between the client and the local file system service can be and in some cases is different from the communication protocol used by the local file system service to communicate with the remote file system.
  • the local file system service acquires results associated with the request to access the file from the remote file system. So, any data or confirmations that are associated with the request for accessing the file are acquired by the local file system service from the remote file system.
  • the local file system service delivers the results to the original requesting user or automated application via its client.
  • junction processing is achieved in a centralized fashion within the user space of multiple clients that comprise a local processing environment.
  • junction processing is handled via each client of the local processing environment in a decentralized fashion.
  • the junction management and file delivery are handled via the local file system service or local file system.
  • the local file system service subsequently detects a change in the path for the file and updates the junction to reflect the change within the local file system when a volume for the path is detected as having been changed.
  • the corresponding junction is updated once for all the clients of the local processing environment in the local file system.
  • a client (can be local to the local processing environment or in some cases remote from the local processing environment) via some client-server access protocol makes a read/write request for some file path, say: “/D1/D2/F2” or “/D1/F1.”
  • the local file system service on the file system server resolves the paths supplied to a junction, such as “J1” but does not return this to the client for further processing (which would be the case in the conventional situations).
  • the local file system service is implemented in the user space, such as FUSE.
  • the local file system service looks for J1 in a volume lookup database (VLDB) by opening J1 and obtaining a GUID that is searched for in the VLDB.
  • VLDB volume lookup database
  • the VLDB then returns the location of the junction, which in the example case being presented is “B:/D2.”
  • the local file system service then directly talks with B looking for “/D2/F2.”
  • B returns the data or result of the file request back to the file system service.
  • the local file system service then returns the data or result of the file request back to the client. So, the client was totally unaware of and did not have to be concerned with any junction processing and yet the client still benefits from the junction processing done by the local file system service from the server and on behalf of the client.
  • the local file system service provides a server-based approach to junction processing. So, special client-side processing to handle junctions is not needed. In this manner, even clients not enabled for junction processing can be integrated and use the local file system service and realize the full benefits of junctions. This also provides for an improved remotely mounted file system experience for LINUX and UNIX users than the current kernel based mount point functionality. Still further the techniques presented herein continue to leverage the fact that server to server communication can in fact use different protocols than the client access protocols to realize access of remote file systems.
  • the techniques allow for data to be moved or changed from one remote server to another or to a different location on a first server without requiring O(N ⁇ M) updates to all of the mount points where N is the number of servers with M mount points.
  • the number of updates needed with the techniques presented herein is O(V) where V ⁇ N or M and V is the number of junctions on the VLDB.
  • FIG. 2 is a diagram of a method 200 for managing access to remote files, according to an example embodiment.
  • the method 200 (herein after “local file system”) is implemented as instructions (within a computer-readable storage medium) that process on a server over a network and is accessed by clients of the network.
  • the network may be wired, wireless, or a combination of wired and wireless.
  • the local file system presents another perspective of the local file system service presented in detail with reference to the method 100 of the FIG. 1 .
  • the local file system provides an enhanced perspective to the method 100 of the FIG. 1 .
  • the local file system services file requests from multiple clients associated with multiple users from a server.
  • the server is associated with a local processing environment. It is noted that clients can be remote and external from the local processing environment and become logically associated with and a part of the local processing environment during a login or authentication process. So, although it is stated that the clients are within the local processing environment this does not just mean in all cases that the clients are within any predefined geographic distance to the local file system and the server. In fact, membership to the local processing environment can be logical and not tied to any geographic distance or presence.
  • the local file system detects when a particular request is associated with a distributed file service (DFS) junction from a remote file system that manages the particular file being requested for a particular request.
  • DFS distributed file service
  • the local file system recognizes the DFS junction as an identifier (GUID) for a volume location (obtained via a mapping in a database) to a remote file system and a path within a remote processing environment of the remote file system for purposes of accessing the particular file.
  • GUID identifier
  • the local file system searches a volume lookup database (VLDB) within the local processing environment with an identifier for the particular file (GUID) to resolve and identify the DFS junction.
  • VLDB volume lookup database
  • GUID identifier for the particular file
  • the VLDB is remotely accessible to the local processing environment and is dynamically consulted over the network.
  • the local file system notes that the VLDB is updated when a change to a particular DFS junction is detected (location with a GUID associated with a junction is changed).
  • the server which is associated with a changed or moved volume, updates and informs the VLDB of the change. The change is immediately available to each of the users and to each of the clients within the local processing environment.
  • the local file system recognizes that the remote file system is not locally mounted within the local processing environment. This triggers the discovery process for acquiring the junction (to get the GUID) and identifying the remote file system (locating the GUID mapping to the remote file system (remote volume)).
  • the remote file system is a completely different file system from that which is associated with the local file system.
  • the type of file system associated with the remote file system is the same type as that which is associated with the local file system.
  • the local file system interacts with the remote file system on behalf of a particular user associated with a particular file to process the particular request.
  • the local file system interacts with the remote file system via communications that are transparent and unknown to the particular user and a particular client, which is associated with the particular user.
  • the local file system uses a server-to-server communication protocol to interact with the remote file system.
  • the protocol used to interact with the clients or the particular client is different.
  • the local file system delivers results from interacting with the remote file system back to a particular client, which is associated with the particular user that made the particular request.
  • the particular client may not include any software or support for junction processing and yet the full benefits of junction processing to access remote files are realized via the processing associated with the local file system.
  • FIG. 3 is a diagram of remote file access system 300 , according to an example embodiment.
  • the remote file access system 300 is implemented as instructions on or within a machine-accessible and computer-readable storage medium.
  • the instructions when executed by machines (computers or processor-enabled devices) of a network (such as the Internet) perform, among other things, processing depicted with respect to the methods 100 and 200 of the FIGS. 1 and 2 , respective.
  • the remote file access system 300 is also operational over a network, and the network may be accessed via a wired connection, a wireless connection, or a combination of wired and wireless connections.
  • the remote file access system 300 includes a local file system service 301 and a volume lookup database 302 . Each of these and their interactions with one another will now be discussed in turn.
  • the local file system service 301 is implemented in a machine-accessible and computer-readable storage medium and is to process as instructions on a server of the network. Example processing associated with the local file system service 301 was discussed in detail above with reference to the methods 100 and 200 of the FIGS. 1 and 2 , respectively.
  • the local file system service 301 is implemented within a local file system that processes on the server. Also, the local file system services multiple users via their clients.
  • the local file system service 301 resolves file request to particular remote file systems via searching of the volume lookup database (VLDB) 302 .
  • the VLDB 302 may be in the same processing environment as the local file system service 301 or may be in a remote processing environment that is accessible to the local file system service 301 .
  • the local file system service 301 directly interacts with those remote file systems to satisfy the file requests on behalf of the users and their clients.
  • the local file system is a flexible user space (FUSE) file system.
  • FUSE flexible user space
  • the local file system service 301 uses different communication protocols to communicate with the remote file systems from that which is associated with the local file system service 301 when it communicates with the clients of the users.
  • a different communication protocol is used to interact with the remote file systems from that which is used to interact with the clients of the local processing environment.
  • the VLDB 302 is implemented in a machine-accessible and computer-readable storage medium on the server of the network and accessible to and managed by the local file system service 301 .
  • the VLDB 302 includes mappings between volume identifiers for files and the remote file systems.
  • the mappings are represented via DFS junctions (GUID's) and locations for those DFS junctions.
  • the local file system service 301 updates a single entry in the VLDB 302 to show an updated particular DFS junction (updated GUID to location mapping within the VLDB 302 ).
  • FIG. 4 is a diagram of another remote file access system 400 , according to an example embodiment.
  • the remote file access system 400 is implemented as instructions on or within a machine-accessible and computer-readable storage medium.
  • the instructions when executed by machines (computers or processor-enabled devices) of a network (such as the Internet) perform, among other things, processing depicted with respect to the methods 100 and 200 of the FIGS. 1 and 2 , respectively.
  • the remote file access system 400 is also operational over a network, and the network is wired, wireless, or a combination of wired and wireless.
  • the remote file access system 400 presents another and in some cases enhanced perspective of the remote file access system 300 represented by the FIG. 3 .
  • the remote file access system 400 includes a local file system service 401 and remote file system service 402 . Each of these and their interactions with one another will now be discussed in turn.
  • the local file system service 401 is implemented in a machine-accessible and computer-readable storage medium and to process on a local server of the network relative to users and their clients.
  • the users and clients may be logically a member of the local processing environment associated with the local server, such as when they authenticate and log into the local server via a remote device or site over the network.
  • Example processing associated with the local file system service 401 was presented in detail above with respect to the methods 100 and 200 and the system 300 of the FIGS. 1-3 , respectively.
  • the local file system service 401 determines when a file is requested from a particular client whether that file is being managed by the remote file system service 402 . If this is the case, then the local file system service 401 directly communicates with the remote file system service 402 to acquire results for the requested file. The results are then delivered by the local file system service 401 to the particular requesting client. This is done without remote mounting techniques and is done via junction control in a centralized and server based administrative approach.
  • the local file system service 401 determines an identity for the remote file system service 402 (remove volume) via a DFS junction lookup within a data store.
  • the data store is being managed locally by the local file system service 401 , although the data store may be remote from the local file system service 401 the data store itself is managed locally by the local file system service 401 .
  • the local file system service 401 uses a different communication protocol to communicate with the remote file system service 402 from that which is associated with other communications made with the clients by the local file system service 401 .
  • the particular client(s) is(are) unaware of the communication between the local file system service 401 and the remote file system service 402 , which occurs to obtain the results for the original file access request.
  • the remote file system service 402 is implemented in a machine-accessible and computer-readable storage medium and to process on a remote server of the network relative to the local server.
  • the remote file system service 402 is of a same type of file system from that which is associated with the local file system service 401 . In other cases, the type of file system associated with the remote file system service 402 is different from that which is associated with the local file system service 401 .

Abstract

Techniques for accessing remote files are presented. A local user, via a local client, requests access to a file. A local file system determines that the file is associated with a junction. The junction is resolved and an associated remote file system is contacted by the local file system to acquire results for the request. The local file system then delivers the results to the local user via the local client.

Description

    BACKGROUND
  • Many modern day operating systems (OS's) have file systems that include the ability to mount a remote file system at a mount point on the local file system for purposes of giving the impression of a single file system that spans both a local partition and a remote file system. The remote file system might be another partition on the local disk or it might be a remote file system that is accessed by a protocol such as Netware Core Protocol (NCP), Server Message Block Protocol (SMB)/Common Internet File System Protocol (CIFS), or Network File System Protocol (NFS).
  • Any remotely mounted file system adds significant value and works well when there are no changes in disk hardware or servers that support the remote file systems; however, when there are changes, the amount and scope of the reconfiguration management steps are significant and grow exponentially with the number of nodes and mount points needed.
  • For example, consider a server “A” that has a remote mount point to server “B.” The mount point on server A includes the identity of server B as well a some sort of location information for B, called “Loc(B).” If Loc(B) ever changes, then the mount point has to be updated. Take for example, if Loc(B) is the IP Address of B and B's address is changed, the mount point on A must be updated. If Loc(B) is the Domain Name Service (DNS) name of B, then B can change its address because the DNS server will then serve up the new address of B and in this case the mount point on A need not be updated. If the location of the file system on B moves, then the mount point on A must be updated. If the file system itself moves from B to C, then the mount point on A must be updated. So, in many cases, if the data on or the location of or even the identity of B ever changes, then the mount points on A must be updated.
  • Now consider 100 servers, A1 through A100, which all have mount points to B. Whenever there is a change to the data on B or the location of B then every mount point on every server A1 through A100 must be updated. Obviously, this is time consuming and inefficient for an enterprise.
  • Therefore, in most cases, a distributed file system is a better way to access data from a remote server by using junctions rather than mount points. A junction is a file, which includes a globally unique identifier (GUID) that identifies the location of a storage volume housing the data associated with the junction. The GUID's mapping to a specific volume for the data is referenced as an entry in a database. If the final location of the data ever changes, no junctions on file systems need to be updated, only the single entry for that GUID in the database needs to be updated. One of the benefits and drawbacks of using a distributed file system is that client software is needed to handle the junction. If the server returns a junction as the result of a request to access a file on the file system, the client will look up the junction file obtain the GUID and look in the database and then find out where the file system is located that hosts the volume of that file and then will “follow” that link to the server that has the data.
  • Take the earlier example of servers A and B, but now there is a junction on A to a file system on B. Client C will ask for a file on A, but if it reaches the junction, A will return the junction to the client C. C will then look up the correct location for the junction in the database (by opening the junction file obtaining the GUID and searching the database for the location), which in this case is a path to a file on B, and then will reference the file on B.
  • Junctions are generally believed to be better than mount points for several reasons. 1) The data from B never has to flow through A in order to reach C. If C needs files that are on A, C talks directly to A. If C finds that files are on B, it will talk directly to B. 2) The junctions are indirect in that the actual location of the data for a junction is stored in the database (via a GUID) rather than on the file system for A. If changes are made to B or where the data is stored on B, only the data in the database needs to be changed (the mapping to the GUID); no changes are needed for any of the junctions on the file system on A.
  • Junction resolution will continue to work even if a volume is moved between servers. This can be done using a volume manager move and split operations. If the entire server is moved to a different server, the data on the original target server will need to be moved using the volume manager operations to make sure database will be updated correctly. (Currently move/split operations require source and target volumes to be within the same processing management context.)
  • Accordingly, a distribute file system adds much value to conventional remote mounting approaches, but one potentially limiting drawback of junctions is that there is client software that is needed on each client to correctly process the junction and to talk to the database. In other words, each of the clients in a distribute file system approach has to be aware of and have software to handle junctions. This creates a support issue for an enterprise, similar to the remote mount discussion presented above.
  • Consequently, there is a need for improved techniques for accessing remote files.
  • SUMMARY
  • In various embodiments, techniques for accessing remote files are presented. In an embodiment, a method for accessing a remote file is presented. A request is received for accessing a file from a client. The request is received at a local file system, which processes on a server and which supports the client and multiple additional clients associated with a local processing environment. A path is resolved to the file across a network as a junction. Next, the junction is used for looking up a remote file system over the network that has the file and that is accessible via the path. The remote file system is contacted over the network with the request for access to the file. Finally, results associated with the request are acquired to access the file from the remote file system and the results are delivered to the client.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a diagram of a method for accessing a remote file, according to an example embodiment.
  • FIG. 2 is a diagram of a method for managing access to remote files, according to an example embodiment.
  • FIG. 3 is a diagram of remote file access system, according to an example embodiment.
  • FIG. 4 is a diagram of another remote file access system, according to an example embodiment.
  • DETAILED DESCRIPTION
  • A “resource” includes a user, content, a processing device, a node, a service, an application, a system, a gateway, a directory, a data store, a World-Wide Web (WWW) site, an end-user, groups of users, combinations of these things, etc. The terms “service,” “module,” “software,” and “application” may be used interchangeably herein and refer to a type of software resource that includes instructions, which when executed by a machine performs operations that change the state of the machine and that may produce output.
  • A “client” or “client workstation” is machine (computer, processing device, etc.) that a user uses to access a network. The client includes a processing environment. As used herein the terms “client,” “desktop,” “client machine,” “client workstation,” and “workstation” may be used interchangeably and synonymously.
  • A “server” is a machine that the client interacts with over a network, such as the Internet. The user, via its client, attempts to establish a connection with the server or to a resource of the server.
  • Various embodiments of this invention can be implemented in existing network architectures, file systems, browsers, proxies, agents, storage systems, security systems, data centers, and/or communication devices. For example, in some embodiments, the techniques presented herein are implemented in whole or in part in the Novell® network, proxy server products, email products, operating system products, data center products, and/or directory services products distributed by Novell®, Inc., of Provo, Utah.
  • Of course, the embodiments of the invention can be implemented in a variety of architectural platforms, file systems, operating and server systems, devices, systems, or applications. Any particular architectural layout or implementation presented herein is provided for purposes of illustration and comprehension only and is not intended to limit aspects of the invention.
  • It is within this context, that various embodiments of the invention are now presented with reference to the FIGS. 1-4.
  • FIG. 1 is a diagram of a method 100 for accessing a remote file, according to an example embodiment. The method 100 (herein after “local file system service”) is implemented as instructions (within a computer-readable storage medium) that process on a server machine (server) over a network and is accessed client machines (clients) of the server. The network may be wired, wireless, or a combination of wired and wireless.
  • At 110, the local file system service receives a request to access a file from a client. A user or automated application makes the request for access via a client. The request is received and processed at a local file system. The local file system processes on the server and supports multiple additional clients and their users/applications, which are associated with a local processing environment.
  • In other words, clients (via users or automated applications) make requests for files that are processed by the local file system at the server and in some cases handled by the local file system service. The local file system service handles requests when any file being requested is associated with a remote file system that is remote from the local processing environment over the network, such as over the Internet.
  • At 120, the local file system service resolves a path to the file across a network as a junction. That is, the path or identifier supplied with the request for access to the file is used to identify that the file being requested is in a remote processing environment from the local file system service and is being managed by a remote file system. The junction provides the ability to resolve the path to a network specific location. The junction is itself a file that includes a GUID for a specific volume of the file being requested, the GUID is mapped to a specific path on the remote file system, such as via a mapping within a database.
  • According to an embodiment, at 121, the local file system service maintains the junction and other junctions, which are associated with other remote file systems and other remote processing environments within a volume lookup database. That is, the GUID's for remote volumes of remote files and their corresponding mappings are retained in the volume lookup database. This is done instead of maintaining and managing mount points for the remote file system and any other remote file systems. Keeping GUID mappings for volumes of files associated with junctions within a volume lookup database allows for easier maintenance and permits changes to be made to locations of remote file systems and files, such that the dependent clients can each effectuate the changes via a single update to the volume lookup database entry. The actual volume lookup database can reside locally to the local file system service or can be accessed remotely on a remote server by the local file system service.
  • Moreover, unlike conventional Distribute File Service (DFS) junction processing, the management and usage of the junctions with the techniques discussed herein occur in a centralized location (at the server and with the local file system service or with the local file system) as opposed to the decentralized approach used in convention DFS junction processing. In the conventional approach each client includes software to handle and manage DFS junction lookup and usage, this means any changes in this software has to be updated to all the clients. With the approaches discussed herein, there is a centralized and file system approach to handling and processing DFS junctions.
  • Continuing with the embodiment discussed at 121, and at 122, the local file system service is enabled for searching the volume database with an identifier for the file being requested. The file identifier is supplied with the original request, which was received from the client. In response to the file identifier, the volume database returns a mapping for the DFS junction (a file that includes a GUID for a remote volume where the file identifier can be found).
  • In another variation, at 123, the local file system service processes the local file system as a flexible user space file system (FUSE). The FUSE looks for and discovers the junction when needed. Again, in some cases, at 124, the local file system service recognizes the junction as a DFS junction.
  • It is noted that in some cases (although not discussed above or with reference to FIG. 1), the requests may be for files that are not associated with a remote file system. In such cases, normal local file system processing can be used as there is no need for any junction resolution in those cases. The local file system service recognizes and assists in processing in the manners discussed herein and above when the file access requests are for files that are remote from the local processing environment and remote from the local file system.
  • At 130, the local file system service looks up the junction (via a junction file to obtain a GUID for the desired volume of the file—the GUID is then mapped to the remote file system via the path) to find a remote file system over the network that has the file and that is accessible via the path.
  • At 140, the local file system service contacts the remote file system over the network with the request for access to the file. So, the local file system service rather than the client directly interacts with the remote file system that houses the file identified by the junction resolution and the path.
  • According to an embodiment, at 141, the local file system service uses a different protocol from that which was used by the client to make the request to the local file system. In other words, the communication protocol used between the client and the local file system service can be and in some cases is different from the communication protocol used by the local file system service to communicate with the remote file system.
  • At 150, the local file system service acquires results associated with the request to access the file from the remote file system. So, any data or confirmations that are associated with the request for accessing the file are acquired by the local file system service from the remote file system.
  • Next, at 160, the local file system service delivers the results to the original requesting user or automated application via its client.
  • In this manner, junction processing is achieved in a centralized fashion within the user space of multiple clients that comprise a local processing environment. Conventionally, junction processing is handled via each client of the local processing environment in a decentralized fashion. With the approaches discussed herein, the junction management and file delivery are handled via the local file system service or local file system.
  • In an embodiment, at 170, the local file system service subsequently detects a change in the path for the file and updates the junction to reflect the change within the local file system when a volume for the path is detected as having been changed. In other words, as file locations change from remoter server to new remote server (volume to volume) or from file path location to new file path structure (different locations within a same volume), the corresponding junction is updated once for all the clients of the local processing environment in the local file system. Again, this can be achieved by changing the GUID mappings and not the actual GUID's included in junction files, it is the mappings that are updated; so technically the junctions themselves remain unchanged.
  • Consider the following illustrating to highlight the processing of the local file system service.
  • A client (can be local to the local processing environment or in some cases remote from the local processing environment) via some client-server access protocol makes a read/write request for some file path, say: “/D1/D2/F2” or “/D1/F1.” The local file system service on the file system server resolves the paths supplied to a junction, such as “J1” but does not return this to the client for further processing (which would be the case in the conventional situations). The local file system service is implemented in the user space, such as FUSE. In this example, the local file system service looks for J1 in a volume lookup database (VLDB) by opening J1 and obtaining a GUID that is searched for in the VLDB. The VLDB then returns the location of the junction, which in the example case being presented is “B:/D2.” The local file system service then directly talks with B looking for “/D2/F2.” B returns the data or result of the file request back to the file system service. The local file system service then returns the data or result of the file request back to the client. So, the client was totally unaware of and did not have to be concerned with any junction processing and yet the client still benefits from the junction processing done by the local file system service from the server and on behalf of the client.
  • Again it is appreciated that the local file system service provides a server-based approach to junction processing. So, special client-side processing to handle junctions is not needed. In this manner, even clients not enabled for junction processing can be integrated and use the local file system service and realize the full benefits of junctions. This also provides for an improved remotely mounted file system experience for LINUX and UNIX users than the current kernel based mount point functionality. Still further the techniques presented herein continue to leverage the fact that server to server communication can in fact use different protocols than the client access protocols to realize access of remote file systems.
  • Moreover, the techniques allow for data to be moved or changed from one remote server to another or to a different location on a first server without requiring O(N×M) updates to all of the mount points where N is the number of servers with M mount points. The number of updates needed with the techniques presented herein is O(V) where V<N or M and V is the number of junctions on the VLDB. So, users have the same file system experience as could be realized with kernel changes but only use changes occurring to user-space code (server file system). Also, better interoperability with remote file systems is permitted along with their various access protocols without requiring client libraries to be implemented and deployed on the various clients that might be accessing the file data.
  • FIG. 2 is a diagram of a method 200 for managing access to remote files, according to an example embodiment. The method 200 (herein after “local file system”) is implemented as instructions (within a computer-readable storage medium) that process on a server over a network and is accessed by clients of the network. The network may be wired, wireless, or a combination of wired and wireless.
  • The local file system presents another perspective of the local file system service presented in detail with reference to the method 100 of the FIG. 1. In some cases, the local file system provides an enhanced perspective to the method 100 of the FIG. 1.
  • At 210, the local file system services file requests from multiple clients associated with multiple users from a server. The server is associated with a local processing environment. It is noted that clients can be remote and external from the local processing environment and become logically associated with and a part of the local processing environment during a login or authentication process. So, although it is stated that the clients are within the local processing environment this does not just mean in all cases that the clients are within any predefined geographic distance to the local file system and the server. In fact, membership to the local processing environment can be logical and not tied to any geographic distance or presence.
  • At 220, the local file system detects when a particular request is associated with a distributed file service (DFS) junction from a remote file system that manages the particular file being requested for a particular request.
  • In an embodiment, at 221, the local file system recognizes the DFS junction as an identifier (GUID) for a volume location (obtained via a mapping in a database) to a remote file system and a path within a remote processing environment of the remote file system for purposes of accessing the particular file.
  • In another case, at 222, the local file system searches a volume lookup database (VLDB) within the local processing environment with an identifier for the particular file (GUID) to resolve and identify the DFS junction. In some cases, the VLDB is remotely accessible to the local processing environment and is dynamically consulted over the network.
  • Continuing with the embodiment at 222, and at 223, the local file system notes that the VLDB is updated when a change to a particular DFS junction is detected (location with a GUID associated with a junction is changed). Actually, the server, which is associated with a changed or moved volume, updates and informs the VLDB of the change. The change is immediately available to each of the users and to each of the clients within the local processing environment.
  • In still another embodiment, at 224, the local file system recognizes that the remote file system is not locally mounted within the local processing environment. This triggers the discovery process for acquiring the junction (to get the GUID) and identifying the remote file system (locating the GUID mapping to the remote file system (remote volume)).
  • It is noted, that in some cases the remote file system is a completely different file system from that which is associated with the local file system. In other cases, the type of file system associated with the remote file system is the same type as that which is associated with the local file system.
  • At 230, the local file system interacts with the remote file system on behalf of a particular user associated with a particular file to process the particular request.
  • According to an embodiment, at 231, the local file system interacts with the remote file system via communications that are transparent and unknown to the particular user and a particular client, which is associated with the particular user.
  • In some cases, at 232, the local file system uses a server-to-server communication protocol to interact with the remote file system. The protocol used to interact with the clients or the particular client is different.
  • At 240, the local file system delivers results from interacting with the remote file system back to a particular client, which is associated with the particular user that made the particular request. The particular client may not include any software or support for junction processing and yet the full benefits of junction processing to access remote files are realized via the processing associated with the local file system.
  • FIG. 3 is a diagram of remote file access system 300, according to an example embodiment. The remote file access system 300 is implemented as instructions on or within a machine-accessible and computer-readable storage medium. The instructions when executed by machines (computers or processor-enabled devices) of a network (such as the Internet) perform, among other things, processing depicted with respect to the methods 100 and 200 of the FIGS. 1 and 2, respective. The remote file access system 300 is also operational over a network, and the network may be accessed via a wired connection, a wireless connection, or a combination of wired and wireless connections.
  • The remote file access system 300 includes a local file system service 301 and a volume lookup database 302. Each of these and their interactions with one another will now be discussed in turn.
  • The local file system service 301 is implemented in a machine-accessible and computer-readable storage medium and is to process as instructions on a server of the network. Example processing associated with the local file system service 301 was discussed in detail above with reference to the methods 100 and 200 of the FIGS. 1 and 2, respectively.
  • The local file system service 301 is implemented within a local file system that processes on the server. Also, the local file system services multiple users via their clients.
  • The local file system service 301 resolves file request to particular remote file systems via searching of the volume lookup database (VLDB) 302. The VLDB 302 may be in the same processing environment as the local file system service 301 or may be in a remote processing environment that is accessible to the local file system service 301. Also, the local file system service 301 directly interacts with those remote file systems to satisfy the file requests on behalf of the users and their clients.
  • In an embodiment, the local file system is a flexible user space (FUSE) file system.
  • According to an embodiment, the local file system service 301 uses different communication protocols to communicate with the remote file systems from that which is associated with the local file system service 301 when it communicates with the clients of the users. In other words, a different communication protocol is used to interact with the remote file systems from that which is used to interact with the clients of the local processing environment.
  • The VLDB 302 is implemented in a machine-accessible and computer-readable storage medium on the server of the network and accessible to and managed by the local file system service 301.
  • In an embodiment, the VLDB 302 includes mappings between volume identifiers for files and the remote file systems. The mappings are represented via DFS junctions (GUID's) and locations for those DFS junctions.
  • In a particular situation, when a particular location for a particular file, which is associated with a particular file request, is changed, the local file system service 301 updates a single entry in the VLDB 302 to show an updated particular DFS junction (updated GUID to location mapping within the VLDB 302).
  • FIG. 4 is a diagram of another remote file access system 400, according to an example embodiment. The remote file access system 400 is implemented as instructions on or within a machine-accessible and computer-readable storage medium. The instructions when executed by machines (computers or processor-enabled devices) of a network (such as the Internet) perform, among other things, processing depicted with respect to the methods 100 and 200 of the FIGS. 1 and 2, respectively. The remote file access system 400 is also operational over a network, and the network is wired, wireless, or a combination of wired and wireless. The remote file access system 400 presents another and in some cases enhanced perspective of the remote file access system 300 represented by the FIG. 3.
  • The remote file access system 400 includes a local file system service 401 and remote file system service 402. Each of these and their interactions with one another will now be discussed in turn.
  • The local file system service 401 is implemented in a machine-accessible and computer-readable storage medium and to process on a local server of the network relative to users and their clients. Although, the users and clients may be logically a member of the local processing environment associated with the local server, such as when they authenticate and log into the local server via a remote device or site over the network. Example processing associated with the local file system service 401 was presented in detail above with respect to the methods 100 and 200 and the system 300 of the FIGS. 1-3, respectively.
  • The local file system service 401 determines when a file is requested from a particular client whether that file is being managed by the remote file system service 402. If this is the case, then the local file system service 401 directly communicates with the remote file system service 402 to acquire results for the requested file. The results are then delivered by the local file system service 401 to the particular requesting client. This is done without remote mounting techniques and is done via junction control in a centralized and server based administrative approach.
  • So, in an embodiment, the local file system service 401 determines an identity for the remote file system service 402 (remove volume) via a DFS junction lookup within a data store. The data store is being managed locally by the local file system service 401, although the data store may be remote from the local file system service 401 the data store itself is managed locally by the local file system service 401.
  • In a particular case, the local file system service 401 uses a different communication protocol to communicate with the remote file system service 402 from that which is associated with other communications made with the clients by the local file system service 401.
  • Thus, the particular client(s) is(are) unaware of the communication between the local file system service 401 and the remote file system service 402, which occurs to obtain the results for the original file access request.
  • The remote file system service 402 is implemented in a machine-accessible and computer-readable storage medium and to process on a remote server of the network relative to the local server.
  • In some cases the remote file system service 402 is of a same type of file system from that which is associated with the local file system service 401. In other cases, the type of file system associated with the remote file system service 402 is different from that which is associated with the local file system service 401.
  • It is now appreciated how users via their clients can reap the benefits associated with junctions to access remote files via remote file systems without having to be configured or include software to handle junction processing or to manage remote mounting. This is done in a centralized fashion and within the user space of the clients, via a server-based approach implemented within a local processing environment's file system.
  • The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
  • The Abstract is provided to comply with 37 C.F.R. § 1.72(b) and will allow the reader to quickly ascertain the nature and gist of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.
  • In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.

Claims (24)

1. A machine-implemented method, comprising:
receiving a request to access a file from a client, wherein the request is received at a local file system, which processes on a server and which supports the client and multiple additional clients associated with a local processing environment;
resolving a path to the file across a network as a junction;
looking up the junction to find a remote file system over the network that has the file and that is accessible via the path;
contacting the remote file system over the network with the request for access to the file;
acquiring results associated with the request to access the file from the remote file system; and
delivering the results to the client.
2. The method of claim 1, wherein resolving further includes maintaining within the local file system a mechanism to resolve the junction and other junctions associated with other remote file systems within a volume lookup database instead of maintaining mount points for the remote file system and the other remote file systems.
3. The method of claim 2, wherein resolving further includes searching the volume lookup database with an identifier for the file, wherein the identifier is supplied with the request from the client.
4. The method of claim 2, wherein resolving further includes processing the local file system as a flexible user space file system that looks for and discovers the junction.
5. The method of claim 4, wherein resolving further includes recognizing the junction as a distributed file service junction.
6. The method of claim 1, wherein contacting further includes using a different protocol from that which was used by the client to make the request when contacting the remote file system.
7. The method of claim 1 further comprising, subsequently detecting a change in the path for the file and updating a mapping associated with the junction to reflect the change within the local file system.
8. A machine-implemented method, comprising:
servicing file requests from multiple clients associated with multiple users from a server associated with a local processing environment;
detecting when a particular request is associated with a distributed file service (DFS) junction for a remote file system that manages a particular file;
interacting with the remote file system on behalf of a particular user associated with the particular file to process the particular request; and
delivering results from interacting with the remote file system back to a particular client associated with the particular user.
9. The method of claim 8, wherein detecting further includes recognizing the DFS junction as an identifier for the remote file system and a path within a remote processing environment of the remote file system to access the particular file.
10. The method of claim 8, wherein detecting further includes searching a volume lookup database within the local processing environment with an identifier for the particular file to resolve the DFS junction.
11. The method of claim 10 further comprising, updating the volume lookup database when a change to a file location for a particular DFS junction is noted, and wherein the change is immediately available to each of the users and each of the clients within the local processing environment.
12. The method of claim 8, wherein detecting further includes recognizing that the remote file system is not locally mounted within the local processing environment.
13. The method of claim 8, wherein interacting further includes interacting with the remote file system via communications that are transparent and unknown to the particular user and the particular client associated with the particular user.
14. The method of claim 8, wherein interacting further includes using a server-to-server communication protocol to interact with the remote file system.
15. A machine-implemented system, comprising:
a local file system service implemented in a machine-accessible and computer-readable storage medium on a server of a network; and
a volume lookup database implemented in a machine-accessible and computer-readable storage medium on the server of the network and accessible to and managed by the local file system service;
wherein the local file system service is implemented within a local file system that processes on the server and that services multiple users via their clients and authenticates the users, and wherein the local file system service resolves file requests to particular remote file systems via searching of the volume lookup database and wherein the local file system service further directly interacts with those remote file systems to satisfy the file requests on behalf of the users and their clients.
16. The system of claim 15, wherein the volume lookup database includes mappings between volume identifiers for files and the remote file systems.
17. The system of claim 16, wherein the mappings are represented as and used to resolve distributed file service (DFS) junctions.
18. The system of claim 17, wherein when a particular location for a particular file associated with a particular file requests is changed, the local file system service updates a single entry in the volume lookup database to show an updated particular DFS junction via a mapping from a particular volume to the particular file to a new particular location.
19. The system of claim 15, wherein the local file system is a flexible user space file system.
20. The system of claim 15, wherein the local file system service uses different communication protocols to communicate with the remote file systems from that which is associated with the local file system service when it communicates with the clients of the users.
21. A machine-implemented system, comprising:
a local file system service implemented in a machine-accessible and computer-readable storage medium and to process on a local server of a network relative to users and their clients; and
a remote file system service implemented in a machine-accessible and computer-readable storage medium and to process on a remote server of the network relative to the local server;
wherein when a file is requested from a particular client, the local file system service determines that the file is being managed by the remote file system service and directly communicates with the remote file system service to acquire results for the requested file, which the local file system service delivers to the particular client.
22. The system of claim 21, wherein the local file system service determines an identity for the remote file system service via a distributed file service (DFS) junction lookup within a data store being managed locally by the local file system service.
23. The system of claim 21, wherein the local file system service uses a different communication protocol to communicate with the remote file system service from that which is associated with other communications made with the clients.
24. The system of claim 21, wherein the particular client is unaware of the communication between the local file system service and the remote file system service that occurs to obtain the results.
US12/115,652 2008-05-06 2008-05-06 Techniques for accessing remote files Abandoned US20090282046A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/115,652 US20090282046A1 (en) 2008-05-06 2008-05-06 Techniques for accessing remote files
US13/284,018 US8171066B2 (en) 2008-05-06 2011-10-28 Techniques for accessing remote files

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/115,652 US20090282046A1 (en) 2008-05-06 2008-05-06 Techniques for accessing remote files

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/284,018 Continuation US8171066B2 (en) 2008-05-06 2011-10-28 Techniques for accessing remote files

Publications (1)

Publication Number Publication Date
US20090282046A1 true US20090282046A1 (en) 2009-11-12

Family

ID=41267726

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/115,652 Abandoned US20090282046A1 (en) 2008-05-06 2008-05-06 Techniques for accessing remote files
US13/284,018 Active US8171066B2 (en) 2008-05-06 2011-10-28 Techniques for accessing remote files

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/284,018 Active US8171066B2 (en) 2008-05-06 2011-10-28 Techniques for accessing remote files

Country Status (1)

Country Link
US (2) US20090282046A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100192121A1 (en) * 2009-01-23 2010-07-29 Microsoft Corporation Debugging remote files using a virtual project
WO2012170234A3 (en) * 2011-06-04 2013-02-07 Microsoft Corporation Clustered file service
EP2629216A3 (en) * 2012-02-16 2014-01-22 Cortado AG Method and system for managing data and a corresponding computer program and a corresponding computer-readable storage medium
US11144251B2 (en) * 2018-10-17 2021-10-12 International Business Machines Corporation Providing a global unique identifier for a storage volume

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109478143B (en) 2016-05-24 2023-01-17 微软技术许可有限责任公司 System and method for accessing remote files

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038379A (en) * 1993-11-09 2000-03-14 Seagate Technology, Inc. Data backup and restore system for a computer network having generic remote file system agents for providing backup and restore operations
US6658461B1 (en) * 2000-05-25 2003-12-02 International Business Machines Corporation Method of, system for, and computer program product for providing a user interface for configuring connections between a local workstation file system and a remote host file system
US20040236798A1 (en) * 2001-09-11 2004-11-25 Sudhir Srinivasan Migration of control in a distributed segmented file system
US6889256B1 (en) * 1999-06-11 2005-05-03 Microsoft Corporation System and method for converting and reconverting between file system requests and access requests of a remote transfer protocol
US6961726B1 (en) * 2000-05-25 2005-11-01 International Business Machines Corporation Method of, system for, and computer program product for storing, retrieving, and using remote host file attributes on a local file system
US20070244989A1 (en) * 2000-12-28 2007-10-18 Scott Ryder Remote Automated Volume Mounting

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038379A (en) * 1993-11-09 2000-03-14 Seagate Technology, Inc. Data backup and restore system for a computer network having generic remote file system agents for providing backup and restore operations
US6889256B1 (en) * 1999-06-11 2005-05-03 Microsoft Corporation System and method for converting and reconverting between file system requests and access requests of a remote transfer protocol
US7080131B2 (en) * 1999-06-11 2006-07-18 Microsoft Corporation System and method for converting and reconverting between file system requests and access requests of a remote transfer protocol
US6658461B1 (en) * 2000-05-25 2003-12-02 International Business Machines Corporation Method of, system for, and computer program product for providing a user interface for configuring connections between a local workstation file system and a remote host file system
US6961726B1 (en) * 2000-05-25 2005-11-01 International Business Machines Corporation Method of, system for, and computer program product for storing, retrieving, and using remote host file attributes on a local file system
US20070244989A1 (en) * 2000-12-28 2007-10-18 Scott Ryder Remote Automated Volume Mounting
US20040236798A1 (en) * 2001-09-11 2004-11-25 Sudhir Srinivasan Migration of control in a distributed segmented file system

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100192121A1 (en) * 2009-01-23 2010-07-29 Microsoft Corporation Debugging remote files using a virtual project
WO2012170234A3 (en) * 2011-06-04 2013-02-07 Microsoft Corporation Clustered file service
CN103608798A (en) * 2011-06-04 2014-02-26 微软公司 Clustered file service
US9652469B2 (en) 2011-06-04 2017-05-16 Microsoft Technology Licensing, Llc Clustered file service
EP2629216A3 (en) * 2012-02-16 2014-01-22 Cortado AG Method and system for managing data and a corresponding computer program and a corresponding computer-readable storage medium
AU2013200859B2 (en) * 2012-02-16 2016-05-12 Cortado Ag Method and system for managing data and a corresponding computer program and a corresponding computer-readable storage medium
US9378217B2 (en) 2012-02-16 2016-06-28 Cortado Ag Method and system for managing data and a corresponding computer program and a corresponding computer-readable storage medium
US11144251B2 (en) * 2018-10-17 2021-10-12 International Business Machines Corporation Providing a global unique identifier for a storage volume
US11797177B2 (en) 2018-10-17 2023-10-24 International Business Machines Corporation Providing a global unique identifier for a storage volume

Also Published As

Publication number Publication date
US20120047170A1 (en) 2012-02-23
US8171066B2 (en) 2012-05-01

Similar Documents

Publication Publication Date Title
US7467203B2 (en) System and methods for robust discovery of servers and services in a heterogeneous environment
US6968345B1 (en) Technique to enable support for symbolic link access by windows clients
US6470332B1 (en) System, method and computer program product for searching for, and retrieving, profile attributes based on other target profile attributes and associated profiles
US8151281B2 (en) Method and system of mapping at least one web service to at least one OSGi service
US7016945B2 (en) Entry distribution in a directory server
CN111567010B (en) Method, system, and storage medium for managing capacity of OPC UA server
JP4671332B2 (en) File server that converts user identification information
US20080320003A1 (en) Scaling network services using dns
EP2740253B1 (en) Method and system for domain name system based discovery of devices and objects
US20030088656A1 (en) Directory server software architecture
US20070112812A1 (en) System and method for writing data to a directory
US20220377050A1 (en) Methods and systems for domain name data networking
US8572201B2 (en) System and method for providing a directory service network
US8171066B2 (en) Techniques for accessing remote files
US20140082285A1 (en) Intercluster relationship management
WO2005106716A1 (en) Systems and methods for providing a proxy for a shared file system
CN107786594B (en) Service request processing method and device
US20240015135A1 (en) Domain management and synchronization system
US10931630B2 (en) System and method for connecting using aliases
US20070106691A1 (en) System and method for efficient directory performance using non-persistent storage
US20080177705A1 (en) Virtual attribute configuration source virtual attribute
US20040243667A1 (en) Generalized proximity service
US20080016234A1 (en) Resolving names to network endpoints
Salnikov et al. DNS-embedded service endpoint registry for distributed e-Infrastructures
CN117640765A (en) Cloud environment service access method and system

Legal Events

Date Code Title Description
AS Assignment

Owner name: NOVELL, INC., UTAH

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ISAACSON, SCOTT ALAN;BALACHANDRAN, NITHYA;SHYAMSUNDAR, R.;AND OTHERS;REEL/FRAME:021057/0193;SIGNING DATES FROM 20080430 TO 20080506

AS Assignment

Owner name: ORACLE INTERNATIONAL CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CPTN HOLDINGS LLC;REEL/FRAME:027146/0521

Effective date: 20110909

Owner name: CPTN HOLDINGS LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NOVELL, INC.;REEL/FRAME:027146/0436

Effective date: 20110427

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION