United States Patent (19)
`Hendricks et al.
`
`(54) METHOD AND APPARATUS FOR
`TRANSLUCENT FILE SYSTEM
`75) Inventors: David Hendricks, Menlo Park; Evan
`Adams, San Leandro; Tom Lyon,
`Palo Alto; Terrence C. Miller, Menlo
`Park, all of Calif.
`73 Assignee: Sun Microsystems, Inc., Mountain
`View, Calif.
`21 Appl. No.: 714,312
`(22
`Filed:
`Jun. 10, 1991
`
`63)
`
`Related U.S. Application Data
`Continuation of Ser. No. 315,287, Jun. 10, 1989, aban
`doned.
`51) Int. Cl. .............................................. G06F 15/40
`52 U.S. Cl. .................................... 395/600; 395/435;
`395/160; 364/DIG. 1; 364/222.81; 364/282.1;
`364/283.1; 364/286
`58) Field of Search ................ 395/600, 425, 146, 160
`(56)
`References Cited
`U.S. PATENT DOCUMENTS
`4,742,450 5/1988 Duvall et al. ....................... 364/200
`4,809,170 2/1989 Leblang et al. ..
`... 395/600
`4,875,159 10/1989 Cary et al. ........
`... 395/600
`4,887,204 12/1989 Johnson et al. ..
`... 395/600
`4,912,637 3/1990 Sheedy et al. ....
`... 395/600
`4,914,569 4/1990 Levine et al.
`... 395/600
`... 395/600
`5,001,628 3/1991 Johnson et al. ..
`... 395/600
`5,077,658 12/1991 Bendert et al. ...
`5,093,779 3/1992 Sakurai ................................ 395/600
`OTHER PUBLICATIONS
`Hughes, Ronald P., "The Transparent Remote File
`System,' Integrated Solutions, Inc. pp. 306–317.
`Gregory, Roger, "XANADU, Hypertext from the Fu
`ture," S Dr. Dobbs Journal, No. 75, Jan. 1983, pp.
`28-35.
`Lewis, Brian T., "Experience with a System for Con
`trolling Software Versions in a Distributed Environ
`ment," Proceedings of the Symposium on Application
`and Assessment of Automated Tools for Software De
`velopment, IEEE Univ. of Texas, 1983, pp. 1-19.
`
`
`
`||||||I||||
`US005313646A
`11
`Patent Number:
`5,313,646
`(45) Date of Patent: May 17, 1994
`
`Interleaf Technical Publishing Software, Reference Man
`ual, vol. 1, Sun/Release 3.0, 1986, pp. 15-1-18, 16-1-19.
`Kleiman, S.R., "Vinodes: An Architecture for Multiple
`File System Types in Sun UNIX," Sun Microsystems,
`pp. 238-247.
`Sandberg, Russel, et al., “Design and Implementation of
`the Sun Network Filesystem,' Sun Microsystems, pp.
`119-130.
`Huskamp, Jeffrey C., "A Modular Operating System
`for the CRAY-1,” Software-Practice and Experience,
`vol. 16(12), Dec. 1986, pp. 1059-1076.
`Tichy, Walter F., “RCS-A System for Version Con
`trol,” Software-Practice and Experience, vol. 15, No.
`7, pp. 637-654, John Wiley & Sons, Ltd., 1985.
`McGilton et al., "Introducing the UNIX System,'
`McGraw-Hill, 1983, pp. 75-78.
`Andrew S. Tanenbaum, "Operating Systems-Design
`and Implementation," Prentice-Hall, Inc., 1987, Chap
`ter 5.
`Primary Examiner-Paul V. Kulik
`Attorney, Agent, or Firm-Erwin J. Basinski
`57
`ABSTRACT
`In a computer system having a hierarchical file struc
`ture, a file system is provided which permits users of the
`system to share a file hierarchy and also have a private
`hierarchy in which files are automatically copied to as
`they are modified. Through the system of the present
`invention, a directory appears to the user as a single
`directory but may actually comprise files originating
`from a number of directories which are connected to
`one another through search links. Each directory has a
`search link associated with it which contains the path
`name of the back layer or directory behind it. The first
`layer seen through the system of the present invention is
`the front layer, private to the user. The back layers
`behind the front layer and connected to the front layer
`through the search links are shared layers accessible to
`multiple users. Thus transparent to the user of the direc
`tory accessible comprises multiple layers comprising
`shared and private files. The system further provides a
`copy-on-write feature which protects the integrity of
`the shared files by automatically copying a shared file
`into the users private layer when the user attempts to
`modify a shared file in a back layer.
`
`16 Claims, 8 Drawing Sheets
`
`Docker EX1011
`Page 1 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 1 of 8
`
`5,313,646.
`
`
`
`F.G. 1
`PRIOR ART
`
`Docker EX1011
`Page 2 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 2 of 8
`
`5,313,646
`
`USER PROGRAMS
`
`USER LEVEL
`
`-
`
`- -
`
`-
`
`- - - - - - -
`
`-
`
`-
`
`- w is
`
`- as a b
`
`is
`
`a up a dis on an as a n
`
`as
`
`as
`
`as as a
`
`a
`
`is as
`
`KERNELLEVEL
`
`SYSTEM CALL AND LIBRARY INTERFACE
`
`
`
`PROCESS CONTROL
`SYSTEM
`
`
`
`KERNEL LEVEL
`
`HARDWARE LEVEL
`
`HARDWARE CONTROL
`
`
`
`HARDWARE
`
`FG. 2
`PRIOR ART
`
`Docker EX1011
`Page 3 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 3 of 8
`
`5,313,646
`
`USER/PROGRAM
`
`70
`
`USERLEVEL
`
`SYSTEM CALL INTERFACE
`
`FILE SYSTEM -
`NTERFACE
`
`PROCESS CONTRO
`SYSTEM
`
`HARDWARE CONTROL
`
`110
`
`100
`
`HARDWARE
`
`80
`
`FIG. 3a
`
`
`
`120
`
`
`
`
`
`Docker EX1011
`Page 4 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 4 of 8
`
`5,313,646
`
`THARWaASN
`
`
`
`THATTANYA
`
`"THADTHN
`
`aUVMCUVH
`
`q¢“OL
`
`
`
`
`
`YJOMIANJOAO$3498
`
`SJHOMLAN SSdD0Ud
`
`
`MIVAGYVHDOANeeeeeeFYVMGUVHAYOMLAN
`
`
`
`Fd0)
`
`WHLLSAS3TdTVOOT
`
`SAL
`
`UdaAYaS
`
`SSdO0O0UdWASN
`
`ouTeyy
`
`Vv
`
`
`
`SOVAYELNITIVOWAELLSAS
`
`
`
`“THARTHNUAY
`
`THATNASN©
`
`
`
`3G0)WYOMLAN
`
`
`
`THARTANYA
`
`TYVAGUVH
`
`Docker EX1011
`Page 5 of 15
`
`Docker EX1011
`Page 5 of 15
`
`
`
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 5 of 8
`
`5,313,646
`
`
`
`Docker EX1011
`Page 6 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 6 of 8
`
`5,313,646
`
`
`
`7 2
`
`C
`
`A
`
`Docker EX1011
`Page 7 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 7 of 8
`
`5,313,646
`
`Gae) o
`
`S “SOI HI
`
`GED NÖ
`
`SIZLOZ
`
`()() ()
`
`SOZ
`
`Docker EX1011
`Page 8 of 15
`
`

`

`U.S. Patent
`
`May 17, 1994
`
`Sheet 8 of 8
`
`5,313,646
`
`s
`
`() ()
`
`a
`
`s
`
`S
`
`ea
`
`5
`
`A.
`
`Docker EX1011
`Page 9 of 15
`
`

`

`1.
`
`5
`
`METHOD AND APPARATUS FORTRANSLUCENT
`FILE SYSTEM
`This is a continuation/divisional of application Ser.
`No. 07/315,287 filed Feb. 24, 1989 now abandoned.
`BACKGROUND OF THE INVENTION
`1. Field of the Invention:
`The field of the Invention is computer systems utiliz
`10
`ing hierarchical file structures, such as the hierarchical
`file structure used in the UNIX operating system envi
`Ornet.
`2. Art Background:
`Computer systems available today range in cost and
`15
`sophistication from low cost micro-processor personal
`computers to sophisticated, high cost mainframe com
`puters. However, the computer systems can be said to
`include the same basic components: at least one central
`processing unit (CPU) which controls the performance
`20
`of computer operations, input/output units which con
`trol the input and output of information within and out
`of the computer system, and memory or storage space
`which stores information used by the CPU to perform
`computer operations.
`25
`The CPU is controlled by the operating system
`which dictates how certain computer operations are to
`be performed. One portion of the operating system is
`the file system module which determines and controls
`the file structure in the computer system.
`One type of file structure in use is referred to as a
`hierarchical file structure. In a hierarchical file struc
`ture files are organized into a tree structure commenc
`ing with a single root node often referred to as the
`"root'. One or more nodes may then be connected to
`the root and one or more nodes may be connected to
`each node. Every non-leaf node of the file system struc
`ture, that is a node which has another node connected
`to it, is a directory of files; and the files at the leaf nodes
`of the tree are either directories, regular files, or a spe
`40
`cial type of file such as a device file.
`In a particular hierarchical file system, the name of
`this file is the path name that describes how to locate the
`file in the system hierarchy. A path name is a sequence
`of component names separated by the "/" character. A
`45
`full path name starts with a "/" character which speci
`fies that a file is found by starting at the file system root
`and traversing the file tree, following the branches that
`lead to successive paths. For example, the path name
`Musr/src/cmd/two.c follows a path such as that shown
`50
`within the box in FIG. 1 and designates the two.c file
`labeled 5 in the tree shown.
`In the software development environment, numerous
`computer programmers may be working concurrently
`on a single program or a group of programs which are
`interrelated and operate together. It is quite desirable
`that the work be done simultaneously so that it may be
`completed in the shortest amount of time. Typically,
`each software programmer makes a copy of those files
`in the portion of the file structure he is working in and
`works on those particular copies to achieve his goal.
`Thus, if a product consists of twenty programs, each
`programmer may have a copy of those twenty pro
`grams in his user area.
`The problem with this arrangement is that each pro
`65
`grammer must usually work with a large number of files
`in order to work on a single file. Consequently, multiple
`copies of these files exist in numerous places on the
`
`5,313,646
`2
`system, requiring a large amount of disk memory space
`and adding to the complexity of the arrangement and
`the identification of the files. Furthermore, it is quite
`easy to lose track of or confuse older versions of pro
`grams with the current versions of programs. For exam
`ple, programmer one may be working on certain por
`tions of a program that has a revision date of may, and
`programmer two may be working on a program that
`has a revision date of June. Thus the changes made by
`either programmer are contained in different versions;
`and, in order to incorporate the new software devel
`oped by the programmers, the code must be incorpo
`rated into the latest version of the code, a repetitive and
`cumbersome task.
`SUMMARY OF THE INVENTION
`It is, therefore, an object of the present invention to
`provide a computer system which contains a file struc
`ture and system comprising a private file hierarchy and
`a shared file hierarchy, the private hierarchy containing
`those files which only the private user has modified.
`It is further an object of the present invention to
`provide a computer system in which shared files are
`written into a private user file automatically if the user
`attempts to modify the file.
`It is another object of the present invention to pro
`vide a computer system in which files may be accessed
`by a common name regardless of the location of the file
`in the file structure.
`It is an additional object of the present invention to
`provide a computer system in which a file directory
`contains both shared and private files.
`In the computer system of the present invention, the
`operating system comprises a translucent file system
`module (TFS) which permits users of the computer
`system to share a file hierarchy and also to have a pri
`vate file hierarchy in which files from the shared hierar
`chy are copied into the private hierarchy only as they
`are modified, a feature referred to as a "copy-on-write'
`procedure. Writing is done only in the private hierar
`chy. Thus, individual users are isolated from changes
`made by others because files in the shared hierarchy are
`guaranteed not to change. In addition, files are only
`copied when they are modified; until modified, the
`shared files are utilized. Consequently, a significant
`amount of disk space is conserved.
`A directory seen through the TFS appears to the user
`as a single directory, but actually comprises listings for
`files or directories which may exist in a number of lay
`ers. Each layer is a physical directory, and the layers are
`joined by what are referred to as search links. Each
`layer has a search link associated with it which contains
`the directory name of the next layer behind it. The first
`layer seen through the TFS is considered to be the front
`layer, and layers found by following the search links
`from this layer are considered to be behind the front
`layer in what are referred to as the "back layers'. The
`files show through from back layers unless the same
`files exist in a layer in front to mask the files in the back
`layers. Therefore, it can be said that the front layer is
`translucent or selectively transparent
`BRIEF DESCRIPTION OF THE DRAWINGS
`The objects, features and advantages of the system of
`the present invention will be apparent from the follow
`ing description in which:
`FIG. 1 illustrates a hierarchical file system structure;
`
`30
`
`35
`
`55
`
`Docker EX1011
`Page 10 of 15
`
`

`

`5
`
`10
`
`25
`
`5,313,646
`4.
`3
`FIG. 2 is a block diagram representation of a UNIX
`The kernel is depicted generally in FIG. 2 which
`based computer system;
`shows three levels: user/programs, kernel and hard
`ware. The system call and library interface represents
`FIG. 3(a) is a block diagram illustrative of the loca
`the border or interface between programs and the ker
`tion of the TFS module system in one embodiment of
`nel. The system calls are divided into those system calls
`the system of the present invention;
`that interface with the file system and those that interact
`FIG. 3(b) is a block diagram illustrative of the loca
`with the process control system. The process control
`tion of the TFS module system in another embodiment
`system is responsible for process synchronization, inter
`of the system of the present invention;
`process communication, memory management and pro
`FIG. 4(a) and 4(b) illustrates a hierarchical file system
`cess scheduling. The file system manages files, allocates
`and the resulting structure visible to the user through
`files space, administers free space, controls access to
`the system of the present invention;
`files and retrieves data for users and programs.
`FIG. 5 illustrates a hierarchical file system employed
`One embodiment of the system of the present inven
`using an embodiment of the system of the present inven
`tion is realized in the system illustrated in FIG. 3(a).
`tion including shared layers and variant layers; and
`The kernel 60 interfaces to the user/programs at the
`15
`FIG. 6 further illustrates the embodiment of the sys
`user level 70 and the hardware at the hardware level 80.
`tem of the present invention described with respect to
`The file system comprises a file system interface 90
`FIG, 4.
`which receives the file system commands and deter
`mines whether the current directory to be accessed is a
`DETAILED DESCRIPTION OF THE
`TFS directory. This is preferably achieved by storing a
`INVENTION
`table or file accessible by the file system interface 90,
`In the system of the present invention, a file system is
`which identifies those directories or file systems which
`provided comprising a Translucent File System module
`are to be accessed through the TFS module.
`(TFS), which provides users with a shared file hierar
`One UNIX-based system is the SUNOS (Sun Operat
`chy and a private hierarchy in which shared files edited
`ing System), produced by Sun Microsystems, Inc.,
`by the user are automatically copied into the user's
`Mountain View, Calif. This operating system includes
`private hierarchy. By means of the TFS module, search
`in its most recent versions, a Network File System
`links are formed for each directory. The search link for
`(hereinafter NFS). The NFS is further described in a
`a directory comprises a pointer stored in the layer with
`paper entitled Design and Implementation of the Sun
`a directory which points to the next directory which is
`Network File System, Sandberg et al, published by Sun
`30
`in the next layer behind the directory. Therefore, files
`Microsystems Inc. Associated with the NFS is a Virtual
`can be accessed from directories or layers which are
`File System (hereinafter VFS). The VFS is a file inter
`behind the front layer by examining the layer identified
`face architecture for accommodating multiple file sys
`through the search links.
`tems within the SUNOS kernel. In particular, the VFS
`The physical layers may be located in one location of
`provides a file system interface which supports local
`35
`memory or storage on one computer system or at multi
`disk file systems such as the 4.2BSD file system, state
`ple locations situated on multiple computer systems
`less remote file systems such as NFS, statefull remote
`linked together through a computer network. When
`file systems such as AT&T's RFS, or non-UNIX file
`ever a user or a process accesses a file, the TFS module
`systems such as MSDOS. The VFS is further described
`causes the most current version of the file to be pres
`in a paper entitled Vinodes: An Architecture for Multiple
`40
`ented for access. Furthermore, if a user requests a direc
`File System Types in Sun UNIX, S. R. Kleinman, pub
`tory listing, the TFS module causes a directory listing
`lished by Sun Microsystems, Inc.
`to be displayed, listing only the most current versions of
`The VFS allows the mounting of different file sys
`the files found among the directories linked together
`tems which require different mount data. To accom
`through search links. The files listed may be shared files
`plish this, in using the system mount command, the file
`45
`located in different back layers or the files may be pri
`system type, the directory which is the mount point, the
`vate files, private to the user and located in the front
`directory to be mounted, various generic flags such as
`layer.
`"read only," and a pointer to the file system specific
`One operating system which uses a hierarchical file
`type data are provided. The mount system command
`structure is the UNIX (E) (UNIX is a registered trade
`accepts as one of its file system types the designation
`50
`mark of AT&T) operating system initially developed by
`TFS.
`Bell Laboratories. Although the preferred embodiment
`Thus, the file system may be identified to be a "TFS
`is described in a UNIX operating system environment,
`type' by the user when the directory or file system is
`it is evident that the system of the present invention may
`mounted. The "mount' command attaches a named file
`be applied to other operating systems employing a hier
`system to a file system hierarchy which is identified by
`55
`a path name location (e.g. "/usr/src"). For example, if a
`archical file structure.
`r
`In a UNIX-based system, the operating system inter
`first file system"/aaa/bbb/ccc' is mounted on a second
`acts directly with the hardware providing common
`file system "/usr/src" the resulting file system consists
`services to programs and isolating the software and
`of "/usr/src/aaa/bbb/ccc". This pathname for the file
`users from the hardware idiosyncrasies of a particular
`system to be attached is the pathname which designates
`computer system. Viewing the system as a set of layers,
`the frontmost writable directory in the TFS system.
`the operating system is commonly called the "system
`If the current directory is a TFS directory, then any
`kernel" or just "kernel", emphasizing its isolation from
`directory command to be executed is executed through
`the user programs. Because the programs are indepen
`the TFS module 95. Otherwise the command is exe
`dent of the underlying hardware, it is easy to move the
`cuted by the non-TFS module, hereinafter referred to as
`65
`programs between UNIX systems running on different
`the "generic file system module' 120. If the command is
`hardware. The UNIX file system, located within the
`to be executed through the TFS module system 95, the
`kernel, organizes the file structures.
`TFS module under control of a TFS server process (a
`
`Docker EX1011
`Page 11 of 15
`
`

`

`5,313,646
`5
`6
`user program) makes requests through the generic file
`front layer, even though the file may be located on a
`system module 120 which provides the proper com
`back layer numerous layers behind the front layer. This
`mands to the hardware control system 110 for causing
`entire operation of searching multiple layers or directo
`the hardware 100 to execute the commands. The TFS
`ries is transparent to the user.
`module system 95, upon receipt of a command, such as
`FIG. 4 illustrates three layers 10, 20 and 30 connected
`one for reading a file or for providing a listing of the
`by search links 40 and 45 containing different versions
`directory, utilizes the search links from the designated
`of files one.c, two.c, and three.c. Layer 30 is the private
`directory and other features particular to the TFS file
`layer and contains files one.c and three.c1 indicating
`system in order to access the most current version of the
`the most current version with respect to the user of
`file or files that may be located in the multiple layers in
`those files, and a white-out marker 60 indicating that file
`the file system.
`X61 is deleted for this user. The files one.c3 and two.c
`A second embodiment of the invention which mini
`are private files signifying that the user had either cre
`mizes the modifications to the kernel is shown in FIG.
`ated the files or had modified the shared versions of the
`3(b). In this embodiment, the TFS file system module is
`files. The layer directly behind the private layer 30, is
`connected through a pre-existing file system module
`layer 20. This is a shared layer and contains the file
`15
`such as the Network File System Module (NFS) which
`one.c2, an earlier version of one.c. File one.c., was
`is connected to the file system interface as a server. The
`copied automatically 75 via copying means 50 into layer
`NFS module directs the command to the NFS server
`30 when the user modified or wrote on the file. Con
`that is bound to, and for the purposes of TFS, the TFS
`nected by search link 40 is shared layer 10 which is
`module is the file server. Therefore, the system com
`behind layer 20. Shared layer 10 contains files one.c
`20
`mands are directed to the TFS module. Since the com
`which is an earlier version of one.c2, file X and file
`mands for operating the NFS module are already in the
`two.c. Using the TFS module of the present invention,
`kernel, when the TFS acts as an NFS server the kernel
`the resulting file structure, that is the file structure visi
`does not have to be modified. Thus, commands relevant
`ble to and accessible by the user is a single directory, a
`to a TFS file system are first directed to the NFS mod
`single layer containing files one.c., two.c and three.c.
`25
`ule where they are forwarded to be executed through
`This is illustrated in FIG. 4(b) in which the files one.c.
`the TFS module. The TFS module then provides the
`and three.c originated from the private layer 30 and file
`layer directories in the manner described.
`two.c originated from the shared back layer 10 are
`In either embodiment of the invention, the user has a
`displayed to the user via display means 72. Thus, it can
`single private front layer. The name of the directory for
`be seen that the complexities of multiple layers are iso
`30
`the front layer is specified at mount time and sent to the
`lated from the user of the system. Furthermore, the
`TFS server process. The TFS server process then fol
`shared files located in the back layers are protected
`Iows the search links from the designated front layer to
`from modification by a user by the copy-on-write fea
`determine the rest of the layers. The searchlinks are
`ture which automatically copies a file into the user's
`originally established by software commands "acquire'
`private front layer when the user attempts to modify the
`35
`and "preserve" in the Network Software Environment,
`file.
`utilities that run on the SUNOS; obviously, other com
`Because the back layers are read only and the private
`mands might be used in other systems. These commands
`layer is the only layer which is read and write accessi
`are used when a file is first viewed by a user and point
`ble, files may only be deleted from the private layer.
`to the next back layer.
`However, if the user has no need for certain files that
`As explained, in the preferred embodiment the search
`are located in back layers, the user can effectively delete
`links for a file system are in a file associated with a
`those files through a "white out" function. The white
`directory and identify the next back directory for the
`out function causes a file which would otherwise be
`layer in back of a particular directory. In effect, a direc
`displayed when a user reviews his directory, to be
`tory is designated as lying in a back layer by the search
`45
`masked-out and not visible or accessible to the user. A
`links pointing to it. When the search links are estab
`file is provided in which the white-out entries are listed.
`lished, the files in that back directory are designated as
`The file is referred to by the TFS module to determine
`read-only by the TFS server process. Although it is
`whether a particular file is to be masked or "whited
`preferred that the search link for each directory be
`out' when file system operations are performed. The
`located in a file associated with that directory, the
`white out entries for a file system may be stored in a
`50
`search links for the entire file system might be located in
`single file in the root directory of the file system. Alter
`a single file situated in a central location such as the root
`natively, the file containing the white-out entries for a
`directory of the file system. The search links identify
`directory may be stored in each directory or the white
`the directories of shared files located in the back layers.
`out entries may be incorporated into the same file con
`The files are designated "shared" simply because of the
`taining the search link. In a preferred embodiment,
`search links which have been established.
`commands may be included for listing the files subject
`When a TFS module receives a command to be exe
`to the whiteout command and for removing the white
`cuted, such as "list a particular file", the TFS directory
`out indication for a particular file.
`identified in the command, which by default is the front
`In another embodiment of the system of the present
`layer, is examined first to determine if the file requested
`invention, conditional search links are provided. A con
`is located in the front layer. If the file is not located in
`ditional search link can point to more than one direc
`the front layer, the TFS module reads the file contain
`tory, wherein the directory pointed to is dependent on
`ing the search link and examines the files in the direc
`the variant used. To accomplish this result, each search
`tory identified in the search link. This process continues
`link provides a string of characters which indicate that
`until the last directory identified through search links is
`there are variants of the search link. In use, the TFS
`read or until the file is found. If the file requested is
`module determines which variant to use from the file
`found, it is identified to the user in the same manner as
`system designation given at the mount command, and
`if it was located in the user's current directory, i.e. the
`the string is replaced by the TFS module with a proper
`
`55
`
`10
`
`65
`
`Docker EX1011
`Page 12 of 15
`
`

`

`O
`
`15
`
`5,313,646
`7
`8
`variant name to read the proper search link to yield the
`variant sub-layer of revision two 210. Thus, only one
`name of the next back layer.
`front writable layer exists, but the layer comprises mul
`tiple sub-layers reflecting shared variant sub-layers.
`These conditional search links are particularly help
`One problem with the invention disclosed to this
`ful where numerous identical source files are used for
`different versions of operating systems since each ver
`point is that as the number of back layers increase, so do
`sion is then capable of compiling its own object code
`the number of search links and the amount of time to
`perform a file system function such as listing the con
`from the same source code.
`Referring to FIG. 5, there two variants, sys3 and sys4
`tents of the directory which requires reading numerous
`which are used on two separate hardware architectures.
`directories and search link files until the last back layer
`is reached. Consequently, in another embodiment of the
`There are two revisions, revision 1 and 2; and each
`system of the present invention, a file look-up cache,
`revision has a variant layer for each of the sys3 and sys4
`variants and a layer 210 shared between the two vari
`referred to as a "back file', is utilized to accelerate file
`look-up and directory read functions.
`ants. The sys3 and sys4 variants both have layers in
`revision two 200, 205 with search links to the shared
`To minimize the amount of time and the number of
`operations required to perform operations with respect
`layer for revision two 210. These search links 206, 207
`to a multi-layered file system, back files are used. The
`have the form "shared/revi" 301 for accessing each
`variant. The "shared' portion 302 is used to identify the
`back file for a directory contains a list of all the read
`"system Number” and the "revif" portion 303 identifies
`only files in the file system and the path names of the
`the revision variant portion of the access link. The
`back layers the files are found in. Thus, to read a direc
`tory, the TFS system needs only to read the directory
`shared layer 210 has a conditional search link 215 to
`20
`$view Rev1. In the preferred embodiment, the "Sview”
`entries of the front layer and the back file for that direc
`tory located in the front layer to determine the names
`is the indication used for a conditional search link.
`When the user looks at the sys3 variant this conditional
`and the actual locations of the files in a file system.
`search link points to the sys3 revision one layer 220 and
`Furthermore, a file located in a back layer can be di
`rectly accessed simply by determining the location
`if the user looks at the sys4 variant the search link points
`25
`to the sys4 revision one layer 225. The sys3 and sys4
`through the back file. The back file is always accurate
`revision one layers 220, 225 have regular, that is, uncon
`because the back layers are read only; that is, the files in
`ditional search links 230, 235 to the shared layer for
`the back layer cannot change so once a file is placed in
`a back layer, it remains in the back layer.
`revision one 240. The conditional search links and the
`shared layers allow files to be shared by different vari
`The back files are written by the TFS process server
`30
`ants so that the source files in the shared layer will be
`when a user looks up a file in a TFS directory or reads
`seen in both sys3 and sys4 variants.
`a TFS directory; if at that time no back file exist for the
`Additionally, protection is provided to prevent a user
`directory, one is created. Normally, this is a simple
`operating in one variant from modifying a source file
`process because there is usually a back file for the direc
`from a shared layer such that the file is copied to the
`tory of the next layer back which can be used to con
`front layer which is variant specific. If this occurs, the
`struct the new back file for the front layer. Thus, usu
`source file is no-longer shared because the most current
`ally only the first read-only layer has to be read for its
`version of the source file is in a user's front layer which
`contents since the locations of the rest of the read-only
`is variant specific and is no longer in the layer shared
`files can be determined from the back file in the first
`read-only layer.
`among the variants. It is therefore preferable that the
`most current version of the source files stay in the
`While the invention has been described in conjunc
`shared layer even when it is modified. This feature is
`tion with preferred embodiments, it is evident that nu
`achieved by providing a front layer comprising sub-lay
`merous alternatives, modifications, variations and uses
`ers: a shared sub-layer and a sub-layer for each variant.
`will be apparent to those skilled in the art in light of the
`foregoing description.
`Thus, any modification performed with respect to a
`45
`shared or variant sub-layer is maintained in the particu
`We claim:
`1. In a multi-user computer system comprising a cen
`lar sub-layer. If a file is found in either of the two front
`sub-layers, the file will be modified in that sub-layer.
`tral processing unit (CPU), an input/output unit and
`memory, said CPU being controlled by an operating
`This is illustrated in FIG. 6. If file one.c in the revision
`system, said operating system comprising a file system
`two shared layer 205, which is the front layer, is modi
`50
`fied by a user who is operating under the sys3 variant,
`module, wherein the file system module organizes and
`the file w