WO1995021416A1 - Distributed file system providing transparent data management - Google Patents

Distributed file system providing transparent data management Download PDF

Info

Publication number
WO1995021416A1
WO1995021416A1 PCT/US1995/001423 US9501423W WO9521416A1 WO 1995021416 A1 WO1995021416 A1 WO 1995021416A1 US 9501423 W US9501423 W US 9501423W WO 9521416 A1 WO9521416 A1 WO 9521416A1
Authority
WO
WIPO (PCT)
Prior art keywords
directory
file
link
providing
repository
Prior art date
Application number
PCT/US1995/001423
Other languages
French (fr)
Inventor
Inc. Cadence Design Systems
Mitchell Richard Lowe
Russell Paul Edwards
Original Assignee
Cadence Design Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cadence Design Systems Inc filed Critical Cadence Design Systems Inc
Publication of WO1995021416A1 publication Critical patent/WO1995021416A1/en

Links

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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/901Indexing; Data structures therefor; Storage structures
    • G06F16/9017Indexing; Data structures therefor; Storage structures using directory or table look-up

Definitions

  • the invention relates generally to the field of distributed processing and storage systems, particularly to methods for improving data management in such distributed systems.
  • the standard approach to this problem is to create a database to represent all of this information, define and store a complex model of all the data files in that database, create a programming interface to access the information in the database, and copy files out of the system when tools need to access the files.
  • the invention resides in an electronic file management system having at least one processor and corresponding storage device wherein a configuration and repository directory are provided, such that a first symbolic reference in the configuration directory links to the repository directory, and a second symbolic reference in the configuration directory links through the first symbolic reference to a file in the repository directory.
  • a configuration and repository directory are provided, such that a first symbolic reference in the configuration directory links to the repository directory, and a second symbolic reference in the configuration directory links through the first symbolic reference to a file in the repository directory.
  • the invention defines a software- implemented method for utilizing the decentralized facilities provided through distributed storage on a computer network made available by distributed file system constructs combined with a prescribed method for using the system to track and process changes made by design engineers, for example, in designs of electronic systems and to combine and integrate those changes into a coordinated set of files that define a consistent state of the electronic system for release to other organizations, including manufacturing groups, both in local and remote physical locations.
  • FIG. 1 is a generalized block diagram of a system according to the present invention.
  • FIG. 2 is a simplified flow chart of a method according to the present invention.
  • FIG. 1 shows a general block diagram of electronic file management system having one or more processor-based 16, 18 nodes, systems or engineering workstations 10, 12, which may be networked 14 using conventional techniques to other such nodes.
  • Each node 10, 12 includes conventional storage devices 20, 22, such as semiconductor and/or disk-based digital memory units.
  • node 10 serves as designer workstation
  • node 12 serves as project manager workstation, in the context of a distributed engineering data system for managing electronic design, particularly managed object configurations or file sets in a given project.
  • nodes 10, 12 may also include in storage 20, 22 an operating system, such as UNIX or VMS, and various computer-aided engineering and design (CAE/CAD) software tools, for example, for circuit schematic capture, logic synthesis, digital or analog simulation, system layout, test vector generation, design documentation, database management, etc.
  • CAE/CAD computer-aided engineering and design
  • nodes 10, 12 may be configured, nonetheless, in the context of other distributed software applications, particularly where complex projects give rise to the generation and management of a large number of files or directories located at multiple storage sites.
  • nodes 10' , 12 ' having corresponding parts such as processors 16' , 18', storages 20' , 22', configuration and repository directories 24', 26', and so on, are distributed across and networked 14 to the system.
  • the apostrophe (') associated with a reference number represents corresponding parts for optional implementations, such as nodes 10', 12' which are functionally equivalent to primary parts corresponding in nodes 10, 12.
  • an electronic file management system or technique enables object or file access by an external software program or other user tool from one to another (or the same) directory, in a flexible and transparent manner.
  • a first or “configuration” storage portion or directory hierarchy 24 is provided 42, preferably in storage 20 of design node 10
  • a second or “repository” storage portion or directory hierarchy 26 is provided 42, preferably in storage 22 of project node 12, as shown in the simplified flow chart of FIG. 2.
  • Directories 24, 26 may be provided in the same node or may be a common directory. (See Appendix-A for simplified sample for directory creation.)
  • a third "shadow" storage portion or directory 26' is similarly provided, including the same file information and directory structure included in repository directory 26. In this way, fault tolerance and data redundancy is provided in case repository directory 26 becomes corrupted or inaccessible.
  • first symbolic reference or link file 40 is provided 44, within configuration directory 24, which defines a direct, virtual data coupling, preferably from repository link file 27 provided in configuration directory 24, to repository directory 26.
  • the repository link in configuration directory 24 is linked symbolically to only one repository directory 26.
  • a symbolic reference or "link” is a file system special file type that points or refers to another named file or object. Such links can span multi-processor or storage device file systems and point to files, directories or other links provided therein.
  • the named file or object to which a link points is indicated by link contents, which include file system path name to the file or object to which such link points.
  • an operating system operation e.g., read, write, close, open, etc.
  • symbolic reference 40 is provided in network or global name space or path name.
  • a network path name is a file system path name that, when used on one computer or node, results in access of a file or object that resides on another computer or node coupled thereto.
  • a global path name is a network path name that can be used on each computer or node coupled to a network (e.g., local or wide area), which resolves to a common file on one of such computers.
  • At least one managed object or data file 32 is provided 46 or copied into repository directory 26 or sub directory thereunder.
  • a file set having more than one version of file 32 may be provided 46 therein.
  • a "managed object” may be composed of many files 32, 34, 36 and optional additional files 32' contained in the repository directory 26. Files that make up a managed object may have paths of the form: ⁇ data-file path>, ⁇ managed object extension:--*.
  • the "managed object extension” is a unique string added to the names of the files composing the managed object 32, 34, 36 stored in the repository directory 26, in order to uniquely distinguish them from each other. (See Appendix-B for simplified sample of managed object creation. )
  • file 32 is provided 46 in repository directory 26 initially by providing such file 32, as "file" 30, in configuration directory 24, possibly generated from external program or tool.
  • Versions of file 30, each version having a unique, positive non-zero integer managed object extension and possibly containing different information, may be created using the check-in process, for instance, when user checks out files for editing and then returns edited file versions therein.
  • a corresponding link file 28 is created for the version created of file 30.
  • file 30 is copied from configuration directory 24 to repository directory 26; then, file 30 is deleted from configuration directory 24.
  • link 28, having the same file name as deleted file 30, may be provided in configuration directory 24 to refer symbolically to copied file 32 in repository directory 26 through link 40, as described further herein .
  • associated text file 34 related to file 32 is provided, preferably identified as "file,@info", in the same directory or sub directory where file 32 is provided.
  • associated file 34 is provided for each managed object or file 32, including information thereof, such as version history, properties, status, user descriptions, check-out/in, etc.
  • file 34 is updated with version number reserved by a check-out operation or version number from which a new managed object is created by an initial checkin operation.
  • file 32 is provided with a unique file name, which relates to a name assigned to corresponding file 28, 30 defined by user or tool.
  • more than one version of file 32 may be stored in repository directory 26, and the system may detect when more than one file 32 is provided 46 with the same file name into repository directory or sub directory thereunder.
  • check-in operation is the mechanism which saves current state of file 30 within repository directory 26. (See Appendix-C for simplified sample of check-in process.) In particular, this operation is done by copying contents of file 30 into a managed object version file 32 within repository directory 26. After copying file 30 into version file 32, operating system access permissions of version file 32 are set not to allow additional modification of version file contents. This restriction is done to preserve contents as they were when check-in operation was performed.
  • the copy of data file within configuration directory 24 is deleted and replaced by a symbolic reference, known as the managed object reference 28 to managed object version into which file 30 was copied 32.
  • the managed object version into which file 30 is copied must have been created by checkout- for-write operation, or never have been checked in before, as described herein.
  • the same user performs both checkout-for-write and check-in operations because version to copy data file into is determined by which version file was checked out by user performing check- in. Preferably, this determination is done by examining contents of managed object's "co. ⁇ user-name>" link.
  • Check-in operation requires three pieces of data on which to operate: (1) configuration directory path 24, (2) file 30 path within configuration directory 24, and (3) binding type specification.
  • Configuration directory path identifies configuration directory 24 and repository directory 26, via configuration directory's repository link 27, which check-in operation is to use; data file path identifies which data file is to be operated on; and binding type specification indicates what type of managed object reference to create.
  • second symbolic reference or link file 28 is provided 48, which defines a direct, virtual data coupling through, or which includes effectively, symbolic reference 40 to file 32.
  • This second symbolic reference is termed a "Managed Object Reference.”
  • symbolic reference 28 is provided in local name space in configuration directory 24 or sub directory therein, according to user-defined link specification or binding type, which indicates type of symbolic reference 28.
  • link 28 Two types of reference to managed object file 32 can be defined by link 28.
  • One type of reference is termed "static.”
  • a static reference is one in which link 28 includes path to link 40 and then the path to file 32 directly within repository directory 26.
  • third symbolic reference or link file 36 is created in repository directory 26 which includes path 38 to file 32.
  • link 36 is identified as "file, ⁇ current" and serves to determine which version file is referenced by dynamic managed object reference.
  • link 28 includes path to link 40 and path to link 36 within repository directory 26.
  • link 28 must be changed to refer to a different file, other than file 32, such that link 28 points to another version of file 32, preferably provided in repository directory 26 or sub directory therein.
  • link 28 or link 36 may be changed to achieve the same result (i.e., accessing a particular version of file 32).
  • link 36 may be caused to refer to version-X of file 32, without changing content of link 28, but effectively changing the file to which link 28 points.
  • dynamic referencing allows link 28 to be fixed once and then remain unchanged, while permitting the file to which accessing is performed to be changed by changing link 36. Note that during the file check-in process, content of link 36 may be changed to point to most recently-created file version.
  • managed object references contain three path name components: (1) reference to repository link 27, (2) directory portion of path to file 32, and (3) file name of one of managed object files for data file.
  • the repository link reference portion is a "relative path" from the directory that the managed object reference is in to the repository link for configuration directory 24. Because of how symbolic links function, this relative path allows contents of the managed object reference to determine the -particular repository directory 26 to which the managed object reference refers. When the managed object reference and repository link are in the same directory, this portion merely contains the name of repository link.
  • the managed object file name component that is selected depends on type of managed object reference.
  • the file name selected is the managed object version corresponding to the version specified in the configuration reference.
  • static references always refer to the same managed object version.
  • the file name selected is the managed object's " ⁇ current" symbolic link.
  • such dynamic links enable the managed object version selected to be controlled by contents of managed object's " ⁇ current” link.
  • an other storage portion or configuration directory 24' is provided, on any node 10' on system network 14, which may include information different from that included in primary configuration directory 24.
  • third symbolic reference or link 40' is provided, which defines a direct, virtual data coupling from the Repository Link 27' in the other configuration directory 24', or sub directory thereunder, to repository directory 26, or sub directory thereunder.
  • fourth symbolic reference 28' provided in corresponding storage 20' of other node 10' similarly links file 32 or other version of file 32' or version of different file 32, 34 provided in repository directory 26 through, or which includes effectively, symbolic reference 40'.
  • an other repository storage portion or directory 26' may be provided, on any node 12' on system network 14, which may include information different from that included in primary repository directory 26.
  • fifth symbolic reference or link 40' is provided, which defines a direct, virtual data coupling from the Repository Link 27' in the configuration directory 24, or sub directory thereunder, to other repository directory 26', or sub directory thereunder.
  • sixth symbolic reference 28' provided in storage 20' of design node 10' similarly links an other object or file 32' provided in other repository directory 26' through, or which includes effectively, symbolic reference 40'.
  • symbolic reference 28 After symbolic reference 28 is provided 48, file 32 may be accessed through such symbolic reference 28 to perform read operation 50.
  • Symbolic Reference 28 is created preferably through checkout-for-read process which provides a reference to the read-only copy of file 32. Alternately, any tool or user program may now access file 32 through Symbolic Reference 28 withouth knowing its version or true location. (See Appendix-D for simplified sample of check-out process for read.)
  • checkout-for-read operation is used to create managed object reference in configuration directory 24.
  • such operation requires three pieces of information on which to operate: (1) configuration directory path, (2) data file path within configuration directory, and (3) binding type specification.
  • configuration directory path identifies configuration directory 24 and repository directory 26 via configuration directory's repository link 27, on which checkout-for-read operation will operate.
  • data-file path identifies which managed object the managed object reference is for, and binding type specification indicates what type of managed object reference to create.
  • version specification is provided for use when static binding type is specified. If dynamic binding type is specified and version specification is provided, version specification is ignored because dynamic managed object reference points to " ⁇ current" link and not a specific version.
  • checkout-for-read operation No modification of a managed object's files is performed by checkout-for-read operation. This restriction is done explicitly to allow users to perform checkout-for-read operation on managed objects which they may not be able modify, because of operating system access restrictions.
  • the act of performing checkout- for-read operation on a data file may be termed “checking the data file out for reading” and after completion, data file may be said to have been “checked out for reading.
  • Checkout-for-read operation does not operate if there is a writable copy of data file in specified configuration directory 24. This restriction is done to prevent accidental loss of data by unintentional use of checkout-for-read operation. If this situation is encountered, such checkout operation will fail, and error is reported. In any other situation, checkout- for-read operation will remove any copy or managed object reference for data-file in configuration directory 24 and replace it with specified managed object reference.
  • file 32 is copied, preferably using a checkout-for-write process to generate a modifiable or writable file copy in configuration directory 24 or a sub-directory thereof.
  • checkout process is used to create a modifiable (i.e., "checked-out") managed object version file for the user performing write operation 52.
  • a modifiable i.e., "checked-out” managed object version file for the user performing write operation 52.
  • an existing managed object version which cannot be modified ordinarily, is copied to create another checked-out version, which is modifiable.
  • a managed object check-out link which records which version was checked-out, may be created by user performing such check-out operation. This link is usable during check-in to determine into which managed object version file the writable file is to be copied.
  • each user may check out one version at a time of a managed object.
  • Configuration directory path identifies configuration directory 24 and repository directory 26, for example, via configuration directory's repository link 27, 40, on which such operation operates.
  • Data file path identifies managed object on which to operate, and version selection option identifies how version' to copy is selected.
  • version selection options There are three different version selection options which may be specified: (1) Current: this option indicates that version to be copied should be the version pointed at by the managed object " ⁇ current" link. (2) Reference: this option indicates that version to be copied should be the version pointed at by the managed object reference for data file in configured directory 24. (3) Version ⁇ version_number>: this option indicates that a version ⁇ version_number> is to be copied. If version ⁇ version_number> does not exist, then checkout-for-write operation fails and reports error.
  • the checked out version is a modifiable copy of specified version 32, which is stored in configuration directory 24 as specified to checkout-for-write operation.
  • managed object's " ⁇ info" file 34 is examined to find the largest version number -used to date for such managed object.
  • the new version is assigned a version number which is one larger than that, and an entry for the newly created version is added to the " ⁇ info" file.
  • the new " ⁇ info" file entry records version number of the newly created version and also records which version number from which it was copied. These entries represent the version derivation history of managed object (i.e., which versions were created from which others) .
  • a managed object checkout symbolic reference or link file is created in repository directory 26 for the user performing checkout-for-write operation.
  • This link is named "co. ⁇ user-name>" , where user-name is replaced by the name of users account on node running checkout- for-write operation. Contents of such link is the name of the newly created managed object version file.
  • ConfigDirPath [Get Path to Configuration Directory]
  • ReposDirPath [Get Path to Repository Directory]
  • RepositoryLinkName " .raw_data"
  • RepositoryLinkPath ConfigDirPath/RepositoryLinkName
  • RepositoryDirectoryPath contents of RepositoryLinkPath symbolic link
  • MOPath RepositoryDirectoryPath/DataFilePath
  • InfoPath MOPath + ", ⁇ info” if (InfoPath exists) ⁇ print "Error - MO already exists for DataFilePath” quit ⁇
  • InfoRecord "1 0" Open InfoPath for Write Write InfoRecord to InfoPath Close InfoPath
  • RepositoryLinkRelativePath " " " for each directory in DataFilePath ⁇
  • RepositoryLinkRelativePath RepositoryLinkRelativePath + " .. /"
  • RepositoryLinkRelativePath RepositoryLinkRelativePath ⁇ +
  • MORContents RepositoryLinkRelativePath + DataFilePath + " , ⁇ current"
  • RepositoryLinkPath ConfigDirPath/RepositoryLinkName
  • DataFileName filename portion of DataFilePath
  • RepositoryDirectoryPath contents of RepositoryLinkPath symbolic link
  • CheckoutPathContents read contents of CheckoutPath
  • CheckedOutVersion [parse version number from CheckoutPathContents]
  • VersionPath MOPath + ", " + CheckedOutVersion Copy ConfigDataFilePath to VersionPath Set OS access permissions of VersionPath to non- modifiable
  • RepositoryLinkRelativePath "" for each directory in DataFilePath ⁇
  • RepositoryLinkRelativePath RepositoryLinkRelativePath + "../" ⁇
  • MORContents RepositoryLinkRelativePath + DataFilePath + ", " + CheckedOutVersion ⁇
  • MORContents RepositoryLinkRelativePath + DataFilePath + ", ⁇ current” ⁇ Delete ConfigDataFilePath
  • RepositoryDirectoryPath contents of RepositoryLinkPath symbolic link
  • RepositoryLinkRelativePath "" for each directory in DataFilePath ⁇
  • RepositoryLinkRelativePath RepositoryLinkRelativePath + "../" ⁇
  • RepositoryLinkRelativePath RepositoryLinkRelativePath + RepositoryLinkName
  • MORContents RepositoryLinkRelativePath + DataFilePath + VersionNumber
  • MORContents RepositoryLinkRelativePath + DataFilePath + ", ⁇ current” ⁇
  • ConfigDirPath [Get ConfigDirpath]
  • DataFilePath [Get data-file-path]
  • ConfigDataFilePath ConfigDirPath/DataFilePath
  • RepositoryLinkPath ConfigDirPath/RepositoryLinkName
  • DataFileName filename portion of DataFilePath if (ConfigDirPath does not exist) ⁇ print "Error - Configuration Directory does not exist" quit
  • RepositoryDirectoryPath contents of RepositoryLinkPath symbolic link
  • MOPath RepositoryDirectoryPath/DataFilePath
  • InfoPath MOPath + ",@info” if (InfoPath does not exists) ⁇ print "Error - MO for DataFilePath does not exist" quit
  • VersionNumber parse version number from CurrentContents
  • VersionNumber [Get Version Number] ⁇
  • NewVersionPath MOPath + " , " + NewVersioiiN- ⁇ mber
  • CheckoutLinkContents DataFileName + " , " + NewVersionNumber if (ConfigDataFilePath exists) ⁇ delete ConfigDataFilePath > copy file VersionPath to ConfigDataFilePath set OS permissions of ConfigDataFilePath to modifiable create symbolic link CheckoutLinkPath with contents CheckoutLinkContents

Abstract

An electronic file management system enables virtual read access to files (30) in a configuration directory (24) by effectively accessing actual copies of such files (32, 34, 36) in a repository directory (26) using symbolic referencing between the directories (40). User-defined symbolic references specify whether static or dynamic linking is established.

Description

DISTRIBUTED FILE SYSTEM PROVIDING TRANSPARENT DATA MANAGMENT
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to the field of distributed processing and storage systems, particularly to methods for improving data management in such distributed systems.
2. Description of Background Art
Design of electronic systems through the use of computer-aided design (CAD) software has and continues to have a dramatic increase in complexity associated with exponential increases in the size and number of data files, number of people involved, and design tools from an increasingly varied set of design tool vendors. There is tremendous pressure to reduce design cycle times, while the complexity of the designs also increases exponentially. Management of the versions of the computer files representing these designs must now be automated given the current and increasing complexity (beyond the ability to cope via manual methods) .
The standard approach to this problem is to create a database to represent all of this information, define and store a complex model of all the data files in that database, create a programming interface to access the information in the database, and copy files out of the system when tools need to access the files.
The problems with this approach are increasing system complexity to the point that nobody can understand the system as a whole, performance problems as additional tools and users attempt to access the database(s) , the inability to integrate all the design tools into the design management system, and the lack of a simple, well-defined method for using the system to achieve the desired result. Further, the ability to customize these systems is very low.
SUMMARY OF THE INVENTION
The invention resides in an electronic file management system having at least one processor and corresponding storage device wherein a configuration and repository directory are provided, such that a first symbolic reference in the configuration directory links to the repository directory, and a second symbolic reference in the configuration directory links through the first symbolic reference to a file in the repository directory. Thus, access of the file in the configuration directory effectively accesses the file in the repository directory.
Preferably, the invention defines a software- implemented method for utilizing the decentralized facilities provided through distributed storage on a computer network made available by distributed file system constructs combined with a prescribed method for using the system to track and process changes made by design engineers, for example, in designs of electronic systems and to combine and integrate those changes into a coordinated set of files that define a consistent state of the electronic system for release to other organizations, including manufacturing groups, both in local and remote physical locations.
Through this invention, complex electronic systems can be designed by a larger number of engineers than otherwise possible without the system, requiring less training of the engineers and less diversion from actual design work, on a distributed network of computers, without undue hardship created by the failure from time to time of portions of the computer network or computers on the network, utilizing the latest and most advanced design tools without any special integration requirements. Designs developed by many engineers can be more easily and accurately assembled into complete and consistent systems. The system is easily customized to optimize the methodology used to assemble electronic systems. BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a generalized block diagram of a system according to the present invention.
FIG. 2 is a simplified flow chart of a method according to the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
FIG. 1 shows a general block diagram of electronic file management system having one or more processor-based 16, 18 nodes, systems or engineering workstations 10, 12, which may be networked 14 using conventional techniques to other such nodes. Each node 10, 12 includes conventional storage devices 20, 22, such as semiconductor and/or disk-based digital memory units.
Preferably, node 10 serves as designer workstation, and node 12 serves as project manager workstation, in the context of a distributed engineering data system for managing electronic design, particularly managed object configurations or file sets in a given project. Thus, nodes 10, 12 may also include in storage 20, 22 an operating system, such as UNIX or VMS, and various computer-aided engineering and design (CAE/CAD) software tools, for example, for circuit schematic capture, logic synthesis, digital or analog simulation, system layout, test vector generation, design documentation, database management, etc.
It is contemplated that nodes 10, 12 may be configured, nonetheless, in the context of other distributed software applications, particularly where complex projects give rise to the generation and management of a large number of files or directories located at multiple storage sites.
Further, it is contemplated that optional nodes 10' , 12 ' having corresponding parts such as processors 16' , 18', storages 20' , 22', configuration and repository directories 24', 26', and so on, are distributed across and networked 14 to the system. Thus, as used herein, the apostrophe (') associated with a reference number represents corresponding parts for optional implementations, such as nodes 10', 12' which are functionally equivalent to primary parts corresponding in nodes 10, 12.
In accordance with the present invention, an electronic file management system or technique enables object or file access by an external software program or other user tool from one to another (or the same) directory, in a flexible and transparent manner. In particular, using conventional operating system commands, a first or "configuration" storage portion or directory hierarchy 24 is provided 42, preferably in storage 20 of design node 10, and a second or "repository" storage portion or directory hierarchy 26 is provided 42, preferably in storage 22 of project node 12, as shown in the simplified flow chart of FIG. 2. Directories 24, 26 may be provided in the same node or may be a common directory. (See Appendix-A for simplified sample for directory creation.)
Optionally, a third "shadow" storage portion or directory 26' is similarly provided, including the same file information and directory structure included in repository directory 26. In this way, fault tolerance and data redundancy is provided in case repository directory 26 becomes corrupted or inaccessible.
Next, first symbolic reference or link file 40 is provided 44, within configuration directory 24, which defines a direct, virtual data coupling, preferably from repository link file 27 provided in configuration directory 24, to repository directory 26. Preferably, at any given moment, the repository link in configuration directory 24 is linked symbolically to only one repository directory 26.
As used herein, a symbolic reference or "link" is a file system special file type that points or refers to another named file or object. Such links can span multi-processor or storage device file systems and point to files, directories or other links provided therein. The named file or object to which a link points is indicated by link contents, which include file system path name to the file or object to which such link points. Thus, when an operating system operation (e.g., read, write, close, open, etc.) is applied to a link, such operation effectively acts on the file to which the links points.
Preferably, symbolic reference 40 is provided in network or global name space or path name. A network path name is a file system path name that, when used on one computer or node, results in access of a file or object that resides on another computer or node coupled thereto. Additionally, a global path name is a network path name that can be used on each computer or node coupled to a network (e.g., local or wide area), which resolves to a common file on one of such computers.
Then, at least one managed object or data file 32, preferably identified initially as "file,l", is provided 46 or copied into repository directory 26 or sub directory thereunder. As described herein, a file set having more than one version of file 32 may be provided 46 therein. A "managed object" may be composed of many files 32, 34, 36 and optional additional files 32' contained in the repository directory 26. Files that make up a managed object may have paths of the form: <data-file path>,<managed object extension:--*. The "managed object extension" is a unique string added to the names of the files composing the managed object 32, 34, 36 stored in the repository directory 26, in order to uniquely distinguish them from each other. (See Appendix-B for simplified sample of managed object creation. )
Preferably, file 32 is provided 46 in repository directory 26 initially by providing such file 32, as "file" 30, in configuration directory 24, possibly generated from external program or tool. Versions of file 30, each version having a unique, positive non-zero integer managed object extension and possibly containing different information, may be created using the check-in process, for instance, when user checks out files for editing and then returns edited file versions therein. At check-in, a corresponding link file 28 is created for the version created of file 30.
To provide each version of file 32 in repository directory 26, file 30 is copied from configuration directory 24 to repository directory 26; then, file 30 is deleted from configuration directory 24. In this way, link 28, having the same file name as deleted file 30, may be provided in configuration directory 24 to refer symbolically to copied file 32 in repository directory 26 through link 40, as described further herein .
Optionally, associated text file 34 related to file 32 is provided, preferably identified as "file,@info", in the same directory or sub directory where file 32 is provided. Preferably, associated file 34 is provided for each managed object or file 32, including information thereof, such as version history, properties, status, user descriptions, check-out/in, etc. For example, file 34 is updated with version number reserved by a check-out operation or version number from which a new managed object is created by an initial checkin operation.
Preferably, file 32 is provided with a unique file name, which relates to a name assigned to corresponding file 28, 30 defined by user or tool. In this way, more than one version of file 32 may be stored in repository directory 26, and the system may detect when more than one file 32 is provided 46 with the same file name into repository directory or sub directory thereunder.
As described herein, check-in operation is the mechanism which saves current state of file 30 within repository directory 26. (See Appendix-C for simplified sample of check-in process.) In particular, this operation is done by copying contents of file 30 into a managed object version file 32 within repository directory 26. After copying file 30 into version file 32, operating system access permissions of version file 32 are set not to allow additional modification of version file contents. This restriction is done to preserve contents as they were when check-in operation was performed.
Additionally, the copy of data file within configuration directory 24 is deleted and replaced by a symbolic reference, known as the managed object reference 28 to managed object version into which file 30 was copied 32. The managed object version into which file 30 is copied must have been created by checkout- for-write operation, or never have been checked in before, as described herein. The same user performs both checkout-for-write and check-in operations because version to copy data file into is determined by which version file was checked out by user performing check- in. Preferably, this determination is done by examining contents of managed object's "co.<user-name>" link.
If there is no version file checked out by the user performing the check-in operation, such operation will fail, and an error is reported. After successfully copying file 30 into version file 32, the managed object's "co.<user-name>" link is removed from repository directory 26. Whenever file 30 is checked in to managed object version file 32 by check-in operation, contents of managed object's "©current" link 36 is modified to point to version file 32. This modification causes dynamic Managed Object References to the managed object to refer automatically to newly checked-in version.
Check-in operation requires three pieces of data on which to operate: (1) configuration directory path 24, (2) file 30 path within configuration directory 24, and (3) binding type specification. Configuration directory path identifies configuration directory 24 and repository directory 26, via configuration directory's repository link 27, which check-in operation is to use; data file path identifies which data file is to be operated on; and binding type specification indicates what type of managed object reference to create.
The act of performing check-in operation on file 30 is termed "checking the data file in" and after completion, such data file is said to have been "checked in." Check-in operation does not operate on managed object references (such as 28) . Performing check-in operation on data file twice in a row is not permitted because the first check-in operation replaces data file with managed object reference. Note that checkout-for- write operation may remove managed object reference, thereby replacing such reference with writable copy of one of managed object's version files. Further, second symbolic reference or link file 28 is provided 48, which defines a direct, virtual data coupling through, or which includes effectively, symbolic reference 40 to file 32. This second symbolic reference is termed a "Managed Object Reference." Preferably, symbolic reference 28 is provided in local name space in configuration directory 24 or sub directory therein, according to user-defined link specification or binding type, which indicates type of symbolic reference 28.
Two types of reference to managed object file 32 can be defined by link 28. One type of reference is termed "static." A static reference is one in which link 28 includes path to link 40 and then the path to file 32 directly within repository directory 26.
Another type of reference is termed "dynamic." To provide a dynamic reference, third symbolic reference or link file 36 is created in repository directory 26 which includes path 38 to file 32. Preferably, link 36 is identified as "file,©current" and serves to determine which version file is referenced by dynamic managed object reference. Further, to provide such dynamic reference, link 28 includes path to link 40 and path to link 36 within repository directory 26. Thus, when read operation 50 on link 28 is performed (e.g., by external program or tool,) the effective result of read operation 50 is the same, such that content of file 32 is read.
Hence, by changing the file to which link 28 references, the file referenced may be redefined. For example, in a static case, link 28 must be changed to refer to a different file, other than file 32, such that link 28 points to another version of file 32, preferably provided in repository directory 26 or sub directory therein. Additionally, in a dynamic case, either link 28 or link 36 may be changed to achieve the same result (i.e., accessing a particular version of file 32). For example, link 36 may be caused to refer to version-X of file 32, without changing content of link 28, but effectively changing the file to which link 28 points. Thus, dynamic referencing allows link 28 to be fixed once and then remain unchanged, while permitting the file to which accessing is performed to be changed by changing link 36. Note that during the file check-in process, content of link 36 may be changed to point to most recently-created file version.
Preferably, managed object references contain three path name components: (1) reference to repository link 27, (2) directory portion of path to file 32, and (3) file name of one of managed object files for data file. In particular, the repository link reference portion is a "relative path" from the directory that the managed object reference is in to the repository link for configuration directory 24. Because of how symbolic links function, this relative path allows contents of the managed object reference to determine the -particular repository directory 26 to which the managed object reference refers. When the managed object reference and repository link are in the same directory, this portion merely contains the name of repository link.
Moreover, the managed object file name component that is selected depends on type of managed object reference. Hence, in the case of static managed object references, the file name selected is the managed object version corresponding to the version specified in the configuration reference. Preferably, such static references always refer to the same managed object version.
In the case of dynamic managed object references, the file name selected is the managed object's "©current" symbolic link. As described further herein, such dynamic links enable the managed object version selected to be controlled by contents of managed object's "©current" link.
Optionally, an other storage portion or configuration directory 24' is provided, on any node 10' on system network 14, which may include information different from that included in primary configuration directory 24. In this implementation, third symbolic reference or link 40' is provided, which defines a direct, virtual data coupling from the Repository Link 27' in the other configuration directory 24', or sub directory thereunder, to repository directory 26, or sub directory thereunder. In this way, fourth symbolic reference 28' provided in corresponding storage 20' of other node 10' similarly links file 32 or other version of file 32' or version of different file 32, 34 provided in repository directory 26 through, or which includes effectively, symbolic reference 40'.
Additionally, an other repository storage portion or directory 26' may be provided, on any node 12' on system network 14, which may include information different from that included in primary repository directory 26. In this implementation, fifth symbolic reference or link 40' is provided, which defines a direct, virtual data coupling from the Repository Link 27' in the configuration directory 24, or sub directory thereunder, to other repository directory 26', or sub directory thereunder. In this way, sixth symbolic reference 28' provided in storage 20' of design node 10' similarly links an other object or file 32' provided in other repository directory 26' through, or which includes effectively, symbolic reference 40'.
After symbolic reference 28 is provided 48, file 32 may be accessed through such symbolic reference 28 to perform read operation 50. Symbolic Reference 28 is created preferably through checkout-for-read process which provides a reference to the read-only copy of file 32. Alternately, any tool or user program may now access file 32 through Symbolic Reference 28 withouth knowing its version or true location. (See Appendix-D for simplified sample of check-out process for read.)
Preferably, checkout-for-read operation is used to create managed object reference in configuration directory 24. As described further herein, such operation requires three pieces of information on which to operate: (1) configuration directory path, (2) data file path within configuration directory, and (3) binding type specification.
In particular, configuration directory path identifies configuration directory 24 and repository directory 26 via configuration directory's repository link 27, on which checkout-for-read operation will operate. Additionally, data-file path identifies which managed object the managed object reference is for, and binding type specification indicates what type of managed object reference to create.
Optionally, version specification is provided for use when static binding type is specified. If dynamic binding type is specified and version specification is provided, version specification is ignored because dynamic managed object reference points to "©current" link and not a specific version.
No modification of a managed object's files is performed by checkout-for-read operation. This restriction is done explicitly to allow users to perform checkout-for-read operation on managed objects which they may not be able modify, because of operating system access restrictions. The act of performing checkout- for-read operation on a data file may be termed "checking the data file out for reading" and after completion, data file may be said to have been "checked out for reading. "
Checkout-for-read operation does not operate if there is a writable copy of data file in specified configuration directory 24. This restriction is done to prevent accidental loss of data by unintentional use of checkout-for-read operation. If this situation is encountered, such checkout operation will fail, and error is reported. In any other situation, checkout- for-read operation will remove any copy or managed object reference for data-file in configuration directory 24 and replace it with specified managed object reference.
Alternately, to perform write operation 52, file 32 is copied, preferably using a checkout-for-write process to generate a modifiable or writable file copy in configuration directory 24 or a sub-directory thereof. Such checkout process is used to create a modifiable (i.e., "checked-out") managed object version file for the user performing write operation 52. (See Appendix-E for simplified sample of check-out process for write. )
In particular, an existing managed object version, which cannot be modified ordinarily, is copied to create another checked-out version, which is modifiable. Also, a managed object check-out link, which records which version was checked-out, may be created by user performing such check-out operation. This link is usable during check-in to determine into which managed object version file the writable file is to be copied.
If the user performing a check-out for write operation already has a checked-out version of the managed object, then such operation fails, and error is reported. Preferably, each user may check out one version at a time of a managed object.
The checkout-for-write operation requires three pieces of information on which to operate: configuration directory 24 path, data file path within configuration directory 24, and version selection option. Configuration directory path identifies configuration directory 24 and repository directory 26, for example, via configuration directory's repository link 27, 40, on which such operation operates. Data file path identifies managed object on which to operate, and version selection option identifies how version' to copy is selected.
There are three different version selection options which may be specified: (1) Current: this option indicates that version to be copied should be the version pointed at by the managed object "©current" link. (2) Reference: this option indicates that version to be copied should be the version pointed at by the managed object reference for data file in configured directory 24. (3) Version <version_number>: this option indicates that a version <version_number> is to be copied. If version <version_number> does not exist, then checkout-for-write operation fails and reports error.
The checked out version is a modifiable copy of specified version 32, which is stored in configuration directory 24 as specified to checkout-for-write operation. Preferably, managed object's "©info" file 34 is examined to find the largest version number -used to date for such managed object. The new version is assigned a version number which is one larger than that, and an entry for the newly created version is added to the "©info" file.
The new "©info" file entry records version number of the newly created version and also records which version number from which it was copied. These entries represent the version derivation history of managed object (i.e., which versions were created from which others) .
A managed object checkout symbolic reference or link file is created in repository directory 26 for the user performing checkout-for-write operation. This link is named "co.<user-name>" , where user-name is replaced by the name of users account on node running checkout- for-write operation. Contents of such link is the name of the newly created managed object version file.
Appendix A SIMPLIFIED SAMPLE OF CREATING A CONFIGURATION DIRECTORY
ConfigDirPath = [Get Path to Configuration Directory] ReposDirPath = [Get Path to Repository Directory] RepositoryLinkName = " .raw_data"
RepositoryLinkPath = ConfigDirPath/RepositoryLinkName
if ( ConfigDirPath does not exist) { create directory ConfigDirPath if (error while creating) { print error quit } } if ( RepositoryLinkPath exists) { print "Error - ConfigDirPath is already a Configuration Directory" quit } create symbolic link RepositoryLinkPath with contents ReposDirPath
if (error while creating link) { print error quit }
Done Appendix B SIMPLIFIED SAMPLE OF CREATING A MANAGED OBJECT
ConfigDirPath = [Get ConfigDirPath] DataFilePath = [Get data file-path] ConfigDataFilePath = ConfigDirPath/DataFilePath RepositoryLinkName = ".raw_data" RepositoryLinkPath = ConfigDirPath/RepositoryLinkName DataFileName = filename portion of DataFilePath
if (ConfigDirPath does not exist) { print "Error - Configuration Directory does not exist" quit }
if (ConfigDataFilePath does not exist) { print "Error - ConfigDataFilePath does not exist" quit }
if (RepositoryLinkPath does not eist) { print "Error - ..." quit }
RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic link MOPath = RepositoryDirectoryPath/DataFilePath InfoPath = MOPath + ",©info" if (InfoPath exists) { print "Error - MO already exists for DataFilePath" quit }
if (MOPath exists and is a directory) { print "Error - DataFilePath is already Checked in as a Directory" quit >
VersionPath = MOPath + ",1"
for all directories in MOPath { if (directory does not exist) { create directory if (error while creating) { print error quit } } }
InfoRecord = "1 0" Open InfoPath for Write Write InfoRecord to InfoPath Close InfoPath
Copy ConfigDataFilePath to VersionPath if (error) { print "Error = Unable to copy file" quit >
Change Access permission of VersionPath to non-modifiable
CurrentPath = MOPath + " ,©current" CurrentContents = DataFileName + ",1"
Create Symbolic link CurrentPath with Contents CurrentContents
RepositoryLinkRelativePath = " " for each directory in DataFilePath {
RepositoryLinkRelativePath = RepositoryLinkRelativePath + " .. /"
} RepositoryLinkRelativePath = RepositoryLinkRelativePath +
RepositoryLinkName
if (BlindingType = STATIC) {
MORContents = RepositoryLinkRelativePath + DataFilePath + ",1" } if (BlindingType = DYNAMIC) {
MORContents = RepositoryLinkRelativePath + DataFilePath + " ,©current"
} Delete ConfigDataFilePath
Create symbolic link ConfigDataFilePath with contents MORContents Done Appendix C SIMPLIFIED SAMPLE OF CHECK-IN PROCESS
ConfigDirPath = [Get ConfigDirPath] DataFilePath = [Get data-file-path] BindingType = [Get BindingType value] ConfigDataFilePath = ConfigDirPath/DataFilePath RepositoryLinkName = ".raw_data"
RepositoryLinkPath = ConfigDirPath/RepositoryLinkName DataFileName = filename portion of DataFilePath
if (ConfigDirPath does not exist) { print "Error - Configuration Directory does not exist" quit }
if (ConfigDataFilePath does not exist) { print "Error - ConfigDataFilePath does not exist" quit }
if (RepositoryLinkPath does not exist) { print "Error - ..." quit }
RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic link MOPath = RepositoryDirectoryPath/DataFilePath InfoPath = MOPath + ",@info"
CheckoutPath = MOPath + ",@co." + <user-account-name>
if (InfoPath does not exist ) { print "Error - MO does not exist for DataFilePath" quit }
if (CheckoutPath does not exist) { print "Error - user <user> does not have DatafilePath checked out" quit }
if (ConfDataFilePath does not exist) { print "Error - no file to checkin" cjuit } if (ConfigDataFilePath is a directory) { print "Error - cannot checkin a directory" quit
}
CheckoutPathContents = read contents of CheckoutPath CheckedOutVersion = [parse version number from CheckoutPathContents] VersionPath = MOPath + ", " + CheckedOutVersion Copy ConfigDataFilePath to VersionPath Set OS access permissions of VersionPath to non- modifiable
CurrentPath = MOPath + " ,©current" CurrentContents = DataFileNa e + ", " + CheckedOutVersion delete CurrentPath create symbolic link CurrentPath with contents CurrentContents
RepositoryLinkRelativePath = "" for each directory in DataFilePath { RepositoryLinkRelativePath = RepositoryLinkRelativePath + "../" }
RepositoryLinkRelativePath = RepositoryLinkRelativePath + RepositoryLinkName if (BindingType = STATIC) {
MORContents = RepositoryLinkRelativePath + DataFilePath + ", " + CheckedOutVersion }
if (BindingType = DYNAMIC) {
MORContents = RepositoryLinkRelativePath + DataFilePath + ",©current" } Delete ConfigDataFilePath
Create symbolic link ConfigDataFilePath with contents MORContents
delete CheckoutPath link
Done
Appendix D SIMPLIFIED SAMPLE OF CHECK-OUT FOR READ OPERATION
ConfigDirPath = [Get ConfigDirPath] DataFilePath = [Get data-file-path] BindingType = [Get BindingType] ConfigDataFilePath = ConfigDirPath/DataFilePath RepositoryLinkName = ".raw_data"
RepositoryLinkPath **■* ConfigDirPath/RepositoryLinkName DataFileNa e = filename portion of DataFilePath
if (ConfigDirPath does not exist) { print "Error - Configuration Directory does not exist" quit }
if (ConfigDataFilePath is a writable file) { print "Error - ConfigDataFilePath is writable, this operation will not overwrite it" quit }
if (RepositoryLinkPath does not exist) { print "Error - ..." quit } RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic link MOPath = RepositoryDirectoryPath/DataFilePath InfoPath = MOPath + ",@info"
if (InfoPath does not exists) { print "Error - MO for DataFilePath does not exist" quit }
if (MOPath exists and is a directory) { print "Error - DataFilePath is Checked in as a Directory" quit }
RepositoryLinkRelativePath = "" for each directory in DataFilePath { RepositoryLinkRelativePath = RepositoryLinkRelativePath + "../" }
RepositoryLinkRelativePath = RepositoryLinkRelativePath + RepositoryLinkName
if (BindingType = STATIC) {
VersionNumber = [Get Version Number] if (no Version Number provided) { CurrentPath = MOPath + ",©current" CurrentContents = read contents of CurrentPath VersionNumber = Parse Managed Object Extension from CurrentContents }
MORContents = RepositoryLinkRelativePath + DataFilePath + VersionNumber
}
if (BindingType = DYNAMIC) {
MORContents = RepositoryLinkRelativePath + DataFilePath + ",©current" }
delete ConfigDataFilePath create symbolic link ConfigDataFilePath with contents MORContents
Appendix E
SIMPLIFIED SAMPLE OF CHECK-OUT FOR WRITE OPERATION
ConfigDirPath = [Get ConfigDirpath] DataFilePath = [Get data-file-path]
VersionSpec = [Get Version Specification]
ConfigDataFilePath = ConfigDirPath/DataFilePath
RepositoryLinkName = ".raw_data"
RepositoryLinkPath = ConfigDirPath/RepositoryLinkName DataFileName = filename portion of DataFilePath if (ConfigDirPath does not exist) { print "Error - Configuration Directory does not exist" quit
} if (ConfigDataFilePath exists and is writable) { print "Error - ConfigDataFilePath is writable, this operation will not overwrite it" quit } if (RepositoryLinkPath does not exist) { print "Error - . . ." quit
}
RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic link
MOPath = RepositoryDirectoryPath/DataFilePath
InfoPath = MOPath + ",@info" if (InfoPath does not exists) { print "Error - MO for DataFilePath does not exist" quit
} if (MOPath exists and is a directory) { print "Error - DataFilePath is Checked in as a Directory" quit
} if (VersionSpec = Reference) {
CurrentPath = MOPath + " ,©current" CurrentContents = read contents of CurrentPath
VersionNumber = parse version number from CurrentContents
} if (VersionSpec = Current) { if (ConfigDataFilePath is not a symbolic link) { print "Error - ConfigDataFilePath is not a Managed Object Reference" quit }
MORContents = read contents of ConfigDataFilePath MORExten = parse MOR Contents for the Managed Object Extension if (error finding Managed Object Extension) { print "Error - ConfigDataFilePath is not a Managed Object Reference" quit } if (MORExten is "©current") {
CurrentPath = MOPath + " ,©current" CurrentContents = read contents of CurrentPath VersionNumber = parse version number from CurrentContents } else {
/* MORExten must be a version number */ VersionNumber = MORExten > } if (VersionSpec = Version) {
VersionNumber = [Get Version Number] }
CheckoutLinkPath = MOPath + " ,©co. " + user account name if (CheckoutLinkPath exists) { print "Error - user <account name> already has DataFilePath checked out" quit
} if (don't have OS access permission to modify InfoPath file OR don't have OS access permission to create file in InfoPath directory) {
print "Error - lack sufficient permission to checkout DataFilePath" quit
>
VersionPath = MOPath = " , " = VersionNumber if (VersionPath does not exist) { print "Error" quit }
LargestVersion = 0 Open InfoPath file for reading for each Record in InfoPath {
Parse record into RecordVersionNumber and RecordDerivedFromVersion if (RecordVersionNumber > LargestVersion) LargestVersion = RecordVersionNumber }
NewVersionNumber = LargestVersionNumber + 1
Construct NewInfoRecord = NewVersionNumber + " " + VersionNumb Write NewInfoRecord to InfoPath for each directory in ConfigDataFilePath { if (directory does not exist) create directory >
NewVersionPath = MOPath + " , " + NewVersioiiN-αmber CheckoutLinkContents = DataFileName + " , " + NewVersionNumber if (ConfigDataFilePath exists) { delete ConfigDataFilePath > copy file VersionPath to ConfigDataFilePath set OS permissions of ConfigDataFilePath to modifiable create symbolic link CheckoutLinkPath with contents CheckoutLinkContents

Claims

CLAIMS We claim:
1. A method for electronic file management comprising the steps of: providing a first and second directory; providing a first link in the first directory to the second directory; providing a first file in the second directory; and providing a second link in the first directory or a sub-directory thereunder through the first link to the first file.
2. The method of Claim 1 wherein: the first and second directory comprise a common directory.
3. The method of Claim 1 further comprising the step of: providing a third directory that includes the same information as included in the second directory.
4. The method of Claim 1 wherein: the first and second links comprise symbolic references.
5. The method of Claim 1 further comprising the step of: providing a fourth directory that includes different information than included in the second directory; providing a third link in the first directory to the fourth directory; providing a second file in the fourth directory; and providing a fourth link through the third link to the second file.
6. The method of Claim 1 wherein: the first file is provided in a sub directory under the second directory.
7. The method of Claim 1 wherein: the second link is provided from a sub directory under the first directory.
8. The method of Claim 1 further comprising the step of: providing in the second directory a third file associated with the first file.
9. The method of Claim 8 wherein: the third file comprises version information about the first file.
10. The method of Claim 1 wherein: the first file is provided with a first name, such that providing another file with the same name is detectable.
11. The method of Claim 1 wherein: a plurality of versions of the first file is provided in the second directory.
12. The method of Claim 1 wherein: the second link is provided according to a user- defined link specification.
13. The method of Claim 12 wherein: the link specification indicates whether the second link is static or dynamic.
14. The method of Claim 12 further comprising the step of: providing in the second directory a third link which refers to the first file.
15. The method of Claim 14 wherein: the second link to the first file is provided also through the third link.
16. The method of Claim 14 wherein: the second link refers to the third link to refer indirectly to the first file.
17. The method of Claim 14 wherein: the second link is pointable either to the first file in static mode or to the third link in dynamic mode.
18. The method of Claim 14 wherein: the third link is modifiable to refer to an other file.
19. The method of Claim 1 further comprising the steps of: providing a fifth directory; providing a fifth link in the fifth directory to the second directory; and providing a sixth link in the firth directory through the fifth link to the first file in the second directory.
20. The method of Claim 1 further comprising the step of: accessing the first file through the second link to perform a read operation.
21. The method of Claim 1 further comprising the steps of: deleting the second link; and copying the first file to the first directory to perform a write operation.
22. The method of Claim 1 wherein: the first link is provided in a network name space .
23. The method of Claim 1 wherein the step of providing the first file in the second directory comprises the following steps: providing the first file in the first directory; copying the first file from the first directory to the second directory; deleting the first file in the first directory; and providing the second link in the first directory to the copied first file in the second directory through the first link.
24. The method of Claim 1 wherein: the second link is provided a link name which is identical to a file name provided to the first file.
25. The method of Claim 1 wherein: the second link is provided with a link name which is identical to a file name provided to a copied file provided in the first directory, wherein the copied file is identical to the first file.
26. A method for object management comprising the steps of: providing a configuration directory and a repository directory; providing a first symbolic reference in the configuration directory to the repository directory; providing an object in the repository directory; and providing a second symbolic reference through the first symbolic reference to the object, wherein the second symbolic reference is provided according to a user-defined specification which indicates whether the second symbolic reference is static or dynamic.
27. A method for electronic file management comprising the steps of: providing a configuration directory and a repository directory; providing a first symbolic reference in the configuration directory to the repository directory; providing a file in the configuration directory; copying the file from the configuration directory to the repository directory; deleting the file in configuration directory; and providing a second symbolic reference through the first symbolic reference to the file copy in the repository directory.
28. The method of Claim 27 wherein: the second symbolic reference is provided according to a user-defined specification which indicates whether the second symbolic reference is static or dynamic.
29. An electronic file management system comprising: at least one processor unit, each processor unit having a corresponding storage device; a configuration directory in one of the storage units; a repository directory in one of the storage units; a first symbolic reference in the configuration directory to the repository directory; a file in the repository directory; and a second symbolic reference for linking through the first symbolic reference to the file; wherein an access to the file in the configuration directory effectively accesses the file in the repository directory.
PCT/US1995/001423 1994-02-04 1995-02-03 Distributed file system providing transparent data management WO1995021416A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US19187494A 1994-02-04 1994-02-04
US8/191,874940204 1994-02-04

Publications (1)

Publication Number Publication Date
WO1995021416A1 true WO1995021416A1 (en) 1995-08-10

Family

ID=22707253

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1995/001423 WO1995021416A1 (en) 1994-02-04 1995-02-03 Distributed file system providing transparent data management

Country Status (1)

Country Link
WO (1) WO1995021416A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658417B1 (en) 1997-12-31 2003-12-02 International Business Machines Corporation Term-based methods and apparatus for access to files on shared storage devices
US6687710B1 (en) 1999-12-03 2004-02-03 Synchronicity Software, Inc. Intellectual property library management system
US6694317B1 (en) 1997-12-31 2004-02-17 International Business Machines Corporation Method and apparatus for high-speed access to and sharing of storage devices on a networked digital data processing system
US7010532B1 (en) 1997-12-31 2006-03-07 International Business Machines Corporation Low overhead methods and apparatus for shared access storage devices
CN115221117A (en) * 2022-08-31 2022-10-21 成都易我科技开发有限责任公司 Method and system capable of transferring data across disks

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355497A (en) * 1992-06-10 1994-10-11 Physiotronics Corporation File directory structure generator and retrevial tool with document locator module mapping the directory structure of files to a real world hierarchical file structure

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355497A (en) * 1992-06-10 1994-10-11 Physiotronics Corporation File directory structure generator and retrevial tool with document locator module mapping the directory structure of files to a real world hierarchical file structure

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MICROSOFT PRESS, 1988, R. DUNCAN, "The MS-DOS Encyclopedia", pages 279-281. *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658417B1 (en) 1997-12-31 2003-12-02 International Business Machines Corporation Term-based methods and apparatus for access to files on shared storage devices
US6694317B1 (en) 1997-12-31 2004-02-17 International Business Machines Corporation Method and apparatus for high-speed access to and sharing of storage devices on a networked digital data processing system
US7010532B1 (en) 1997-12-31 2006-03-07 International Business Machines Corporation Low overhead methods and apparatus for shared access storage devices
US7275059B2 (en) 1997-12-31 2007-09-25 International Business Machines Corporation Methods and apparatus for high-speed access to and sharing of storage devices on a networked digital data processing system
US7299232B2 (en) 1997-12-31 2007-11-20 International Business Machines Corporation Low overhead methods and apparatus shared access storage devices
US6687710B1 (en) 1999-12-03 2004-02-03 Synchronicity Software, Inc. Intellectual property library management system
CN115221117A (en) * 2022-08-31 2022-10-21 成都易我科技开发有限责任公司 Method and system capable of transferring data across disks

Similar Documents

Publication Publication Date Title
US5551028A (en) Design data management system and associated method
US6298319B1 (en) Incremental compilation of electronic design for work group
Katz et al. A version server for computer-aided design data
Feiler Configuration management models in commercial environments
KR970004101B1 (en) The database system saving, restoring, migrating apparatus, the database system, and a method of saving, restoring, migrating the same
US6826604B2 (en) Input/output device information management system for multi-computer system
US5274806A (en) Hierarchical data encyclopedia
Stojanovic et al. Ontology Evolution within Ontology Editors.
Katz Managing the chip design database
Pu et al. Regeneration of replicated objects: A technique and its Eden implementation
Ganger et al. Self-* storage: Brick-based storage with automated administration
US5787280A (en) Apparatus and method for providing a facility for managing versions and configurations of persistent and transient objects
US6427230B1 (en) System and method for defining and managing reusable groups software constructs within an object management system
US6857000B2 (en) Object-oriented data storage and retrieval system using index table
Sidle Weaknesses of commercial data base management systems in engineering applications
US10146827B2 (en) Object based content management system and method
US20070255765A1 (en) Systems and methods for file maintenance
Wiil et al. Hyperform: A hypermedia system development environment
Colyer et al. Depot: A tool for managing software environments
Reichenberger VOODOO A Tool for orthogonal version management
Nestor Toward a persistent object base
WO1995021416A1 (en) Distributed file system providing transparent data management
Lamersdorf Recursive data models for non-conventional database applications
US7480789B1 (en) Virtual file system interface to configuration data of a PLD
Liu Design data management in a CAD framework environment

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

WA Withdrawal of international application
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA