United States Patent 1:
`Bauer
`
`CARAA
`
`US005412808A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,412,808
`May 2, 1995
`
`[54]
`
`[75]
`
`[73]
`
`[21]
`
`[22]
`
`[63]
`
`[51]
`[52]
`
`[53]
`
`[56]
`
`SYSTEM FOR PARSING EXTENDEDFILE
`NAMESIN AN OPERATING SYSTEM
`
`Inventor:
`
`Eric J. Bauer, Tinton Falls, N-J.
`
`Assignee:
`
`AT&T Corp., Murray Hill, NJ.
`
`Appl. No.:
`Filed:
`
`29,345
`
`Mar. 10, 1993
`
`5,218,696 6/1993 Baird et al. cecsssesssesesnus 395/600
`
`5,224,038
`6/1993 Bespalko ..
`5,333,317
`7/1994 Dart -.cscessseccessseeseeeescseree 395/600
`
`OTHER PUBLICATIONS
`
`Tichy, “RCS-A System for Version Control’, Soft-
`wave-Practice and Experience, vol. 15(7), 637-654 Jul.
`1985.
`
`Related U.S. Application Data
`Continuation of Ser. No. 735,394, Jul. 24, 1991, aban-
`doned.
`
`Tint, CUS ooosecesecsssccseccesessssscseeuteseseeceees GO6F 15/40
`US. Che cescsccscsssssssesscsaseanee 395/600; 364/DIG.1;
`364/222.81; 364/282.3; 395/700
`Field of Search o.oo. 395/600, 650, 700;
`364/419; 84/622
`
`References Cited
`U.S.PATENT DOCUMENTS
`
`4,413,318 11/1983 Herrington oe 395/650
`4,758,951
`7/1988 Sanyter et al. oe 364/200
`4,825,354 4/1989 Agrawal et al.
`......
`-
`4,914,586 4/1990 Swinehart etal.....
`4,993,030
`2/1991 Krakaueretal. .....
`4,999,766
`3/1991 Petersetal. .........
`wee 84/622
`5,119,711
`6/1992 Bell et al...
`5,202,982 4/1993 Gramlich et al. 02.0...vase 395/600
`
`
`
`
`Primary Examiner—Thomas G. Black
`Assistant Examiner—Wayne Amsbury
`Attorney, Agent, or Firm—John A. Caccuro
`
`[57]
`
`ABSTRACT
`
`A file system of a computer operating system includes
`files which may have one or more data streams associ-
`ated with them. The files are accessed using a base name
`and the associated data stream(s) are accessed using a
`prefix and/or a suffix of the base name. For example,
`the base name is used to select a data file while the
`prefix and/or suffix is used to access data streams
`which, illustratively, include information used by the
`file system in the processing of the data file. Using this
`file naming structure enables the file system to handie
`the base name file and its associated data streams to-
`gether as onefile using the standard file commands.
`
`20 Claims, 5 Drawing Sheets
`
`
`
`RETURN SUCCESS WITH
`REFERENCE TO FOUND
`FILE OBJECT
`
`
`
`
`
`
`RETURN SUCCESS ALONG WITH
`REFERENCE TO THE SELECTED
`DATA STREAM OF THE OBJECT
`“BASE NAME”
`
`Google Exhibit 1086
`Google v. VirtaMove
`
`Google Exhibit 1086
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`May 2, 1995
`
`Sheet 1 of 5
`
`5,412,808
`
`FIG.
`PRIOR ART
`
`1
`
`COMPUTER BASED FILE SYSTEM
`
`|
`
`USER LEVEL 120
`
`KERNEL LEVEL 130
`
`HARDWARE LEVEL 140
`
`HARDWARE DRIVER
`CHARACTER 1/0]
`[BLOCK 1/0]
`
`

`

`U.S. Patent
`
`May2, 1995
`
`Sheet 2 of 5
`
`5,412,808
`
`FIG. 2
`
`DATA
`212
`
`RESOURCE
`113
`
`
`
`EXT. ATTRIBUTES|2. [STREAM SHE |
`
`
`
`LOGICAL STRUCTURE OF FILE 200
`INODE
`
`
`
`FILE MODE
`|
`FILE OWNER
`
`
`FILE'S GENERATION NUMBER
`LAST ACCESS TIME
`
`OTHER FILE ATTRIBUTES
`
`
`STREAM SIZE
`
`
`TIME OF LAST STREAM MODIFICATION
`
`
`STREAM DIRECT DATA BLOCKS
`|
`
`
`
`——
`STREAM INDIRECT DATA BLOCKS
`
`
`
`
`
`
`
`214
`
`
`
`
`
`UMD ATIRBLTES|3. [STERN SE )
`
`
`
`
`sr
`
`
`DATA BLOCKS 224
`
`PHYSICAL STRUCTURE OF -FILE SYSTEM 220
`
`

`

`U.S. Patent
`
`May2, 1995
`
`Sheet 3 of 5
`
`5,412,808
`
`FIG. 3
`
`PATH DELIMITERS
`
`310~~PATHNAME-Ke
`
`FILE NAMES
`
`S1IS~FILE SYSTEM
`TREE
`
`”/~R0OT
`
`HOME
`aN
`JOP
`BIN
`
`PASSWORD
`
`MEMOIRS
`
`320 ~~ FILE NAMES — <PURPORTED-FILE NAME>
`MAY COMPRISE
`
`521 ~~ <PREFIX><BASE NAME><SUFFIX>
`<2.><MEMOIRS><.1>
`
` 330 ~~ BASE NAME TYPES
`
`31 ~ A CONVENTIONAL “PHYSICAL” FILE NAWE
`ie., USR OR "BIN
`332 —~ A PRESCRIBED SYNTAX
`SYNTAX 1 - ie, "ino =X, gen = 1"
`SYNTAX 2 - A MORE FLEXIBLE SYNTAX
`"FIND: USER = ROOT, MODE = 644°
`SYNTAX 3 - A DATABASE QUERY
`SYNTAX 4 - A NATURAL LANGUAGE SYNTAX SELECTION CRITERIA
`333 ~~ A NAME THAT IS MATCHED USING A NON-SUBSTRING-BASED
`CRITERIA,
`i.¢., PHONETIC MATCHING
`
`

`

`U.S. Patent
`
` —— May 2, 1995
`
`Sheet 4 of 5
`
`5,412,808
`
`
`
`403
`
`ves
`
`[ENTRY NOT
`
`RECEIVE FILE Nawe} 4°?
`WA_CREATE() JES"1sFREATSET
`NO
`Ml]
`ENwu FOUND, ERROR
`|
`
`ELIMINATE TRAILING DELiMiTerS|4/1
`~
`(SLASHES)
`IN PATH NAME
`
` STRIP LEADING NAME COMPONENT
`
`SET WORKING DIRECTORY TO
`ROOT OR CURRENT DIRECTORY
`
`OFF OF PATH NAME
`
`421
`
`(A) FIG. 5
`427
`
`REFERENCE THE CURRENT
`WORKING DIRECTORY
`REFERENCE PARENT OF
`425
`CURRENT WORKING a
`pet
`NO
`PERFORM FILE SYSTEM-
`SPECIFIC LOOKUP SEF FIG. 5
`429
`
`
` 435
`
`LOOKUP OK
`
`(B) FIG. 5
`NO
`RY
`NO
`FOUND, ERROR
`
`3f
`
`MORE
`FILE NAME COMPONENTS
`IN PATH
`NO.
`
`439
`
`RETURN SUCCESS, WITH A
`REFERENCE 70 THE CURRENT OBJECT
`
`

`

`U.S. Patent
`
`May2, 1995
`
`Sheet 5 of 5
`
`5,412,808
`
`FIG. 3
`
`302
`
`NO_T
`
`ACCESS ERROR
`
`YES
`
`503
`
`PREFIX
`D/OR SUFFIX USED
`
`NO
`
`
` 513
`Sti
`
`[STRIP PREFIX AND/OR SUFFIX
`FROM PURPORTED FILE NAME
`|
`TO PRODUCE "BASE NAME”
`[SEARCH DIRECTORY
`FOR ENTRY "BASE NAME"
`nC
`
`BASE NAME FOUND
`
`307
`
`YE
`
`5
`
`NO
`ENTRY NOT FOUND ERROR
`
`|
`
`K>*!
`
`(B)FIC. 4
`RETURN SUCCESS WITH
`REFERENCE 10 FOUND
`__FILE OBECT
`NO
`
`|
`
`
`
`
`RETURN SUCCESS ALONG WITH
`REFERENCE TO THE SELECTED
`DATA STREAM OF THE OBJECT
`"BASE NAME"
`
`
`
`
`
`S15”
`
`AIG. 4
`
`FIG. 6
`
`TABLE 600
`
`"16° - EXTENDED ATTRIBUTES
`
`CONFIGURED PREFIXES AND SUFFIXES
`
`
`
`"26" - MAC RESOURCE FONT
`
`
`"UNX@” - "UNIX EXTENDED ATTRIBUTES”
`
`"OLD@" - OLD VERSION OF FILE
`
`
`"Cl@" - COMPILED/INTERPRETED VERSION OF FILE
`
`

`

`1
`
`5,412,808
`
`SYSTEM FOR PARSING EXTENDED FILE NAMES
`IN AN OPERATING SYSTEM
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`
`This application is a continuation of application Ser.
`No. 07/735,394, filed on Jul. 24, 1991, and now aban-
`doned.
`Related subject matter is disclosed in my other appli-
`cation filed concurrently herewith and assigned to the
`same assignee hereof: U.S. patent application Ser. No.
`07/735,393, entitled “Method and Apparatus for Ac-
`cessing a Computer-Based File System”, now aban-
`doned.
`
`15
`
`TECHNICAL FIELD
`
`The present invention relates to a computer system
`and, more particularly, to the accessing of a file system
`thereof.
`
`20
`
`BACKGROUND OF THE INVENTION
`
`Operating systems exist today which havea file sys-
`tem which enables the user to access one or more data
`streams of a file (where a data stream is a sequence of
`data bytes). In one example, the APPLE ® MACIN-
`TOSH ® Hierarchical File System, two data streams
`are supportedperfile: one stream is called the data fork,
`and the other is called the resource fork APPLE and
`MACINTOSH are registered trademarks of Apple
`Computer, Inc.). A programmer selects a particular
`stream via a combination ofa file name and a bit param-
`eter to open a stream and then uses conventional file
`system calls (e.g., read 0, write 0, IseekO, etc.) to oper-
`ate on that data stream. Undesirably, if a new fork (data
`stream) is added to the file system, and consequently a
`new bit parameter required, existing programs must be
`rewritten to permit access to the new data streams.
`Such program rewrites are a costly overhead for the
`user.
`
`The OS/2 ® operating system available from IBM,is
`another hierarchical file system. (OS/2 is a registered
`trademark of International Business Machines Corpora-
`tion). The High Performance File System offered by
`OS/2 aiso supports two data streamsperfile: one stream
`contains the nodal file data, while the other stream
`contains extendedattribute information which has been
`associated with this file. In OS/2, different operating
`system calls are used to manipulate each of the two data
`streams. Such an arrangement requires a separate set of
`operating system calls when a new data stream is added.
`Undesirably, existing programs must be rewritten when
`new operating system calls are added to the OS/2 reper-
`toire.
`Whatis desired is a technique which enables an oper-
`ating system to access an ever-increasing number of
`data streamsof anyfile in a manner which is compatible
`with existing operating system calls and commands,
`thereby eliminating the need to rewrite existing pro-
`grams.
`
`SUMMARY OF THE INVENTION
`
`In accordance with the apparatus and method ofthe
`present
`invention, a file system accesses previously
`stored data files using a file name defined as including a
`base name and at least one appended segment. The
`appended segment(s) may be a prefix, a suffix, or both a
`prefix and suffix of the base name. Whena file access
`
`45
`
`55
`
`60
`
`65
`
`2
`request is received, the file name is parsed into a base
`name and a segment(s). The base nameis used to search
`the stored files to obtain a desired file. An appended
`segment is then used to select for access a data stream
`associated with the desired base namefile. The present
`invention thus enables a file system to access the data
`streamsof any file in a manner which is compatible with
`existing operating system calls and user level commands
`thereby eliminating the need to rewrite existing pro-
`grams.
`According to other features of the invention, an ap-
`pended segment may be used to access attributes of a
`stored file, or to designate an operating system to be
`used to process a particular data stream.
`BRIEF DESCRIPTION OF THE DRAWING
`
`in the drawing
`FIG.1 illustrates a block diagram of a computer and
`its operating system which is useful in describing the
`operation of the present invention;
`FIG. 2 showsthe logical and physical structure of a
`file and a file system;
`FIG. 3 defines various terms useful in describing the
`present invention;
`FIGS. 4 and 5 illustrate a flow chart describing vari-
`ous operating features of the present invention; and
`FIG.6 is a table illustrating examples of various pre-
`fixes and suffixes used by the present invention.
`HIGH LEVEL DESCRIPTION
`
`In the following description, each, item or block of
`each figure has a reference designation associated there-
`with, the first number of which refers to the figure in
`which that item is first located (e.g.; 110 is located in
`FIG. 1 and step 501 is located in FIG.5).
`FIG. 1 depicts a computer based file system 100
`which operates under control of a UNIX ® operating
`system 110, shown using a high-level architecture layer
`diagram. (UNIX is a registered trademark of UNIX
`System Laboratories, Inc. (hereinafter USL)). The layer
`diagram includes a user level 120, a kernel level 130, and
`a hardware level 140. The user level 120 interfaces to a
`user 101 enabling access to the file system 100 to obtain
`the desired file stored in memory (e.g., disk 180).
`Theuser level 120 includes the user programs 121 and
`libraries 122. The hardware level 140 provides the oper-
`ating system 110 with basic services needed by com-
`puter 100. The kernel level 130 interacts directly with
`the hardware level 140 providing commonservices to
`user level] 120 programsand insulating them from hard-
`ware idiosyncrasies. Viewing the system as a set of
`layers, the operating system is.commonly called the
`system kernel 130, or just the kernel, emphasizing its
`isolation from user programs. Because user programs
`are independentof the underlying hardware,it is easy to
`move them between UNIX systems running on differ-
`ent hardware. The general description of the well-
`known operation of a UNIX operating system is de-
`tived from Chapter 2 of the book entitled “The Design
`of the UNIX Operating System” by Maurice J. Bach.
`The system call interface 131 represents the border
`between user level 120 (user programs 121 and program
`libraries 122) and the kernel level 130. System call inter-
`face converts user program calls into UNIX system
`calls. System calls look like ordinary function calls in C
`programs, and libraries map these function calls to the
`primitives needed to enter the operating system in a
`
`

`

`3
`well-known manner. The set of system calls includes
`those that interact with the file system driver 132 and
`those that interact with the process control subsystems
`133. The file system driver 132 managesfiles, allocating
`file space, controlling access to files, and retrieving data
`for users. Processes interact with the file system driver
`132 via a specific set of system calls, such as open (to
`open a file for reading or writing), close, read, write,
`star (query the attributesof a file), chown (change the
`record of who ownsthefile) and chmod (change the
`access permissionsofa file). The file system driver 132
`accesses file data using a buffer 136 that regulates data
`flow between the kernel and secondary storage devices.
`The buffering mechanism interacts with block I/O de-
`vice drivers 137 to initiate data transfer to and from the
`kernel. Device drivers 134 are the kernel modules that
`control the operation of peripheral devices. Block I/O
`devices 141 are random access storage devices; alterna-
`tively, their device drivers 137 make them appear to be
`random access storage devices to the rest of the system.
`For example, a tape driver may allow the kernel to treat
`a tape unit as a random access storage device. The file
`system also interacts directly with “raw” or character
`J/O device drivers 138 without the intervention of a
`buffering mechanism. Raw devices, sometimes called
`character I/O devices 142, include all devices that are
`not block devices.
`The process control subsystem 133 is responsible for
`process synchronization, interprocess communication,
`memory management, and process scheduling. Thefile
`system driver 132 and the process control subsystem
`133 interact when loadinga file into memory for execu-
`tion. The process contro! subsystem 133 reads execut-
`able files into memory before executing them.
`Some of the system calls for controlling processes
`include the following: fork (create a new process), exec
`(overlay the image of a program onto the running pro-
`cess), exit (finish executing a process), wait (synchro-
`nize process execution with the exit of a previously
`forked process), brk (control the size of memory allo-
`cated to a process), and signal (control process response
`to extraordinary events).
`Aspreviously noted, file system 100 enables the user
`to access files stored on disk 180. A “file” is best viewed
`as a logical information object which may include one
`or more data streams and which has an owner and per-
`missions and other attributes, and one or more file
`names. A data stream is best viewed as an independent
`sequenceof data bytes that can grow orshrink indepen-
`dent of any other data streams on the machine. Hence,
`the following are file operations: rename, link, change
`ownership, change group ownership, and change mode.
`The following are data stream operations: read, write,
`and lock (a portion of a data stream).
`With joint reference to FIGS.1, 2 and 3 we describe
`an overview ofa file system. Every file is named by one
`or more path names, 310. A path name, as shownin 310,
`includes file names(e.g., home) separated by delimiters
`(/). The internal representation ofa file is given by an
`inode, which contains a description of the disk layout of 60
`the file data and other information such as the file
`Owner, access permissions, and access times. The term
`inode is a contraction of the term index node and is
`commonly used in literature on the UNIX system.
`Every file has one inode, but it may have several path
`names, all of which mapinto the inode. Each path name
`is called a link. When a process refers to a file by path
`name, the kernel parses the path name onefile name
`
`40
`
`45
`
`55
`
`65
`
`5,412,808
`
`20
`
`25
`
`35
`
`4
`componentat a time, checks that the process has per-
`mission to search the directories in the path, and eventu-
`ally retrieves the inode for the file. For example, if a
`process makes the call “open (/home/jqp)” the kernel
`retrieves the inode for “/home/jqp”. As shown by 315
`a “file system tree” for a full path namestarts with a
`slash character (’’/“) and specifies that the path nameis
`relative to the “root”ofthe file system tree. Following
`the branches that lead to successive component names
`of the path name “/home/jqp/2@memoirs” designates
`a full path name while “home/2@memoirs”does not. A
`path name does not haveto start from root but can be
`designated relative to the “current directory” of an
`executing process by omitting the initial slash in the
`path name. Thus, starting from current directory
`“/home”, the path name “Bin” designatesthe file whose
`full path nameis “/home/Bin”’.
`In accordance with the present invention, the file
`name 320 or purported file name may be considered to
`include a prefix, a base name anda suffix and the prefix
`and suffix can be used to select alternate data streams of
`the particular file (file system object) designated by base
`name. A base name 330, as shown in FIG. 3, may be a
`conventional “physical”file name 331, (typically stored
`in a directory) or a prescribed syntax 332 or a non-sub-
`string-based name 333 which are described in myprevi-
`ously referenced co-pending patent application whichis
`incorporated herein by reference.
`When a process creates a new file, the file system
`driver 132 assigns it an unused inode. Inodes are stored
`in a section 223 of the physical file system 220, as will be
`described shortly, but the file system driver 132 reads
`them into an in-core-memoryinode table when manipu-
`lating files. The UNIX system typically keeps regular
`files and directories on block devices such as disks. An
`installation may have several physical disk units each
`containing one or morefile systems. A file system 220is
`organized as a sequenceoflogical blocks, each contain-
`ing 512, 1024, 2048, or any convenient multiple of 512
`bytes, depending on the system implementation. Multi-
`ples of 512 are used by convention and thereis no intrin-
`sic reason to use 512 byte blocks.
`A physical file system may have the physical struc-
`ture illustrated by 220 of FIG. 2. The boot block 221
`(only on somefile systems) occupies the beginning of a
`file system, typically the first sector, and may contain
`the bootstrap code thatis read into the machineto boot,
`or initialize the operating system. Although only one
`boot block 221 is needed to boot the system, every file
`system may have a (possibly empty) boot block. The
`super block 222 describes the state of a file system—-
`how largeit is, how manyfiles it can store, where to
`find free space on thefile system, and other information.
`The inodelist 223 is a list of inodes that follows the
`super block in the file system. Administrators specify
`the size of the inode list 223 when configuring a file
`system. The file system driver 132 references inodes by
`index into the inode list 223. One inodeis the root inode
`of the file system: it is the inode by which the root
`directory structure of the file system is accessible after
`execution of the mount system call. The data blocks 224
`start at the end of the inodelist and hold the contents of
`data streams (i.e., file data). An allocated data block
`contains the actual data of a data stream ofa file and can
`belong to one and only onefile in the file system.
`The operation of the present invention will be de-
`scribed as utilized in an Enhanced File System (EFS)
`implemented on a UNIX system using a virtual file
`
`

`

`5,412,808
`
`6
`5
`The file system 132 keeps track of each of the
`system. Some UNIX systems use a Virtual File System
`streams, and assures that they are each independent in
`(VFS) concept to organize all file system operations.
`the way that they are accessed, and yet consistent for
`Althoughthe present invention does not require a VFS
`file operations (e.g., rename, change ownership.. . ).
`mechanism, VFS provides a convenient conceptual
`model to explain the invention. VFSis a merge of the
`DETAILED DESCRIPTION
`System V File System Switch (FSS) and the SUN OS
`VFS mechanism.It is important to note that user pro-
`grams will be unaffected by the SVR4.0 VFSarchitec-
`ture.
`VFS provides a file system type independentinter-
`face to programs and users while allowing each particu-
`lar file system to process file system operations in their
`own manner. File system type dependent kernel rou-
`tines do the work specific to the type.
`A keystrength of VFSis that it allows newfile sys-
`tem types to be defined and implemented by third-party
`software houses. The set of kernel interfaces that consti-
`tute VFS are available in a VFS file system type writ-
`ers’ guide available from USL.
`GENERAL DESCRIPTION
`
`20
`
`With reference to the layer diagram of FIG. 1 we
`now provide a more detailed operating description of
`the present invention.
`With joint reference to FIGS. 1 and 4 wedescribe the
`detailed operation of the present invention. The present
`invention is implemented to perform a file system-
`specific lookup feature as part of the standard lookup
`path name feature which occurs during a conversion of
`a path name to a vnode. The present invention permits
`a single inode to contain multiple data streams, so the
`term vnodeshall be usedto refer to the virtual node that
`is associated with a particular data stream. Hence, with
`four data streamsperfile, them will be four vnodes per
`inode. Unless otherwise stated, a vnoderefers to the Oth
`data stream of a file.
`Theinitial access to a file is by its path name, as in the
`open, chdir (change directory), or link system calls.
`Because the kernel 130 works internally with vnodes
`rather than with path names, it converts the path names
`to vnodes to access files. An algorithm of the UNIX
`system kernel parses the path name one file name com-
`ponent at a time, convening each component into a
`vnode based on its name and the directory being
`searched, and eventually returns the vnode of the input
`path name.
`The steps 401-425 and steps 429-439 illustrate the
`existing steps of the path name to vnode conversion
`which are briefly described so that the detailed opera-
`tion of the present invention (FIG.5) can be explained
`in a typical operating context.
`When a user program 121 makes a processcall, e.g.,
`open (path name, open vnodeflag), the operating sys-
`tem kernel (hereinafter kernel) 130 generates the com-
`mand vn_open(name, seg,file mode, create mode, vpp,
`crwhy) in step 401. The command vn—open performs
`permission checks and opensa file by name, returning a
`pointer to the resulting vnode. In the command vn_o-
`pen the parameter name contains the path name;seg is
`the address spacethe file nameis in, either user space or
`kernel space; file mode is the open mode; create mode
`contains the permission bits if the file is to be created;
`vpp is a pointer to a vnode pointer for the result; and
`crwhy is the reason whythis routineis called, it is de-
`fined if and only if file mode has the Fcreate bit set.
`_In step 402 a file nameis received from the user pro-
`gram 121. In step 403, the kernel 130 checksif the Fcre-
`ate bit is set. If so, then in step 405 a command vn_cre-
`ate( ) is generated in the conventional manner. The
`command of vn_—create indicates to the kernel 130 that
`the process cali wishes to create a new file, an operation
`which is well-known and not important to an under-
`standing of the present invention.
`If the Fcreate bit is not set then in step 407 the path
`nameis checked to determineif one exists. In our exam-
`ple, recall the path nameis “/home/jqp/2@memoirs”.
`If path name was a aull then in step 409 an “entry not
`found”error is returned to the system user.
`If path nameis not a null then in step 411 the trailing
`delimiters or slashes in the path name are eliminated.
`(Note our example has no trailing slashes after “mem-
`oirs’”’). In step 413,if the first character of ‘name’ is a “/”’
`character (indicating a path namestarting at root), then
`
`The present invention permits access to each of these
`data streams in a mannerthat is compatible with existing
`UNIX systems via special file names. This special file
`naming scheme uses a file name which includes a base
`name and a prefix, a suffix or both. Additionally, the
`present invention can be utilized with any operating
`system which accessesfiles by file name.
`An overview of the capabilities of the present inven-
`tion will, illustratively, be described with reference to a
`file name comprising only a prefix and a base name.
`Obviously, a file name which uses a base name and
`suffix combination or a prefix, base name and suffix
`combination could also be used to obtain the same capa-
`bilities.
`The present invention,as utilized in an Enhanced File
`System (EFS), uses a file name prefix string to permit
`access to non-default data streams. For example, the
`default EFS configuration may operate as follows: the
`file name “foo” accesses the default (Oth) stream of file
`“foo’’. That is, the absence ofa prefix in front of “foo”
`results in the access of the default or null (Oth) data
`stream, the file name “1@foo” accesses the Ist stream of
`file “foo”,
`the file name “2@foo” accesses the 2nd
`stream offile “foo,” the file name “3@foo” accesses the
`3rd stream of file “foo” and so on. This prefixing
`scheme permits all streams to be manipulated by exist-
`ing UNIX applications (e.g., vi(1), sh(i)) and services
`(e.g., Remote File System (RSF)).
`One use of these multiple data streams can be to sup-
`port multiple client operating systems. For example,
`both the MACINTOSH HFSand OS/2’s High-Perfor-
`mance File System (HPFS) support two data streams
`per file. In both the MACINTOSH HFS and OS/2
`HPFSthe resource fork and extended attribute data are
`used to hold data such as icons, fonts, history, subject
`information, application-specific configuration parame-
`ters, etc.
`Utilizing the present invention, a UNIX-based file
`system may support file servers for heterogeneouscli-
`ent machines (e.g, MACINTOSH and OS/2) as fol-
`lows: stream 0, e.g., 212, contains the shared (regular)
`data; stream 1, e.g., 213, contains the MACINTOSH
`Resource fork; stream 2, e.g., 214, may contain the
`OS/2 extended attribute data, and other streams; e.g.,
`215 may be used for secondary data or extendedattri-
`butes for other operating systems, such as the UNIX
`system.
`
`25
`
`35
`
`45
`
`55
`
`60
`
`65
`
`

`

`7
`to root, otherwise the
`the working directory is set
`working directory is set to the current directory. In step
`415, it is determined whether the working directory is a
`directory. If not, then in step 417 a “not in directory”
`error is returned to the user. If working directory is a
`directory, then in step 419 the leading file name compo-
`nent (i.e., “home” in our example) is stripped off the
`path name.
`the stripped off file name component
`In step 421,
`“home” is compared to “.” If equivalent, then in step
`423 the system will reference the current working direc-
`tory and then control returns to step 415. If file name
`componentis not “.” then in step 425 it is compared to
`“..”. If equivalent to “..” then in step 427 the parent of
`the current working directory is referenced and control
`returns to step 415. Otherwise, step 427, the file system-
`specific lookup feature of the present invention,as illus-
`trated in FIG.5, is performed on the stripped-off file
`name “home ”.
`Thefile system-specific lookup feature will be de-
`scribed in moredetail in a later paragraph,but suffice it
`to say that the stripped-off file name “home” includes
`no prefix or suffix (as shown by 321 ). Hence,after the
`steps of FIG. 5 are performed on the file name “home”
`it returns to step 429 with a vnode reference to access
`thefile object of thefile “home ”. If no vnode reference
`was found then an error is returned to the user in step
`431. Otherwise, in step 433, the system checks if the
`vnode reference refers to a data object which is a sym-
`bolic link. If so, then in step 435, the contents of the link
`are placed at the front of the remaining path name.
`Otherwise, in step 437 the system determines whether
`there are more file name componentsin the path name.
`If no more file name components then in step 439 con-
`trol is returned with a vnode reference to the data ob-
`ject. If more file name components exist then controlis
`returned to step 415 for further processing.
`With reference to FIG. 5 we now describe the pres-
`ent invention, as illustratively embodied, as a file sys-
`tem-specific lookup feature. We describe the processing
`of the file name “home” of our example path name
`“/home/jqp/2@memoirs”. In step 501 the requester’s
`execute permission in the current directory is checked
`in the standard way. If permission does not exist an
`access erroris returned to the user in step 502. If permis-
`sion exists, then in step 503, a check is made to deter-
`mine if a prefix or suffix exists. Recall from FIG.3 that
`file name 320 may include three segments, a prefix, a
`base name and a suffix. Some possible prefixes and suf-
`fixes are listed in Table 600 of FIG. 6 whichis stored as
`part of super block 222 of FIG. 2. If no prefix or suffix
`is found then processing continues to step 507. Recall in
`our example file name “home” no prefix or suffix is
`used. Since the file name “home” does not contain any
`of the possible prefixes listed in Table 600 of FIG. 6, in
`step 505, the base nameis equivalent to the file name
`“home” and the current directory is searched for the
`base name.
`If, however,a prefix or suffix match is found in Table
`600, a software flag is set indicating respectively that a
`prefix and/or suffix match exists. Basically, a prefix or
`suffix match is determined by comparing each prefix
`and suffix located in Table 600 with the file name. Pre-
`fixes and suffixes are typically stored in the super block
`ofthe file system.
`In step 505 any prefix or suffix is stripped from the
`purported file name to producethe “‘base name”. In step
`507, the directory is searched using the “base name”
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`35
`
`60
`
`65
`
`5,412,808
`
`8
`resulting when the file nameis stripped of any prefix or
`suffix. In step 509 if a “base name”is found in the direc-
`tory, then in step 511 the prefix or suffix flags are
`checked. If no prefix or suffix is found then in step 513
`control returns the vnode associated with the Oth data
`stream base name. Thus, for our example, for file name
`“home ”, the vnode for the Oth data stream of the
`“home” file object would be returned to step 429 of
`FIG. 4 for continued processing in the previously de-
`scribed manner.
`If a prefix or suffix was found in the file name, then
`the feature returns the success status along with the
`reference vnode of the selected data stream of the ob-
`ject base name.
`Thus,
`in our example, path name “/home/jqp/2-
`@memoirs”after the file name “home”is processed via
`steps 501, 503, 507, 509, 511, 513 and then by steps 429,
`433 and 437. Subsequenily, in step 415, 419, 421, 425 and
`427 the file name “‘jqp” is processed. Since “jqp” has no
`prefix or suffix, it is processed in the same manner as
`“home ”, i.e., by steps 501, 503, 507, 509, 511, 513 and
`then by steps 429, 433 and 437. After processing file
`names “home” and “jqp”’ the file name “2@memoirs”is
`processed in a similar manner. Thus, steps 415, 419, 421,
`425 and 427 are performed. However, since “2@me-
`moirs” has a prefix,i.e.,.““2@”step 505 is performed and
`a prefix flag is set. Thus, processing proceeds from step
`501,503, 505, 507, 509 511 to step 5 15. In step 5 15, the
`feature returns the success along with the reference
`vnode of the data stream specified by prefix “2@” for
`the file named “memoir”. For example, the data stream
`specified by prefix “2@” may specify fonts or icons that
`should be utilized with the text of the “memoirs”file.
`The various types and uses of prefixes and suffixes are
`described in a later paragraph.
`With reference to Table 600 of FIG. 6, we briefly
`describe examples of some of the various configured
`prefixes and suffixes that can be utilized by the present
`invention. If the base nameis referred to as the physical
`file name the combination of the <prefix> <base
`name> <suffix> can be referred to as a virtual file
`name where eachofthe virtual file names share the data
`with the base namefile. One example of an application
`of the virtual file name capability would be to simulate
`on a UNIX system the MACINTOSH (MAC)file name
`structure,
`ie., “file name, bit” where bit
`indicates
`whetherthe file is the data file or resourcefile. Accord-
`ing to the present invention, a prefix or suffix would
`identify the bit information, e.g., <bit> <file name>
`or <file name> <bit>, respectively, to the UNIX
`system. Another application would be to provide an
`OS/2 attribute capability to a UNIX system. In OS/2 a
`file name is followed by a prefix or suffix thereby per-
`mitting the extended attribute data to be accessed via
`standard file system primitives, e.g., open, read, write,
`close, lock.
`Note, the examples described below as a prefix may
`also be utilized as a suffix. The prefix types of Table 600
`may be represented by one or moredigits, characters or
`symbols. For example, the prefix “1@” may represent
`“extended attributes” of an OS/2 system while prefix
`“2@” may represent the resource file of a MACIN-
`TOSH system. The prefix “unx@” may represent a
`UNIX system extended attribute capability. Other ex-
`amples of prefixes may include “old@”to signify an
`older version of the base namefile, while “CI@” may
`represent the compiled or interpreted version of the
`base namefile.
`
`

`

`9
`While the present invention has been described as
`acce