« PreviousContinue »
PARSE FILE NAME TO EXTRACT
REQUESTED "ORG NAME"
key, relational look-up, phonetic spelling look-up, and METHOD AND APPARATUS FOR OPERATING A find-operator look-up to locate one or more stored data COMPUTER BASED FILE SYSTEM objects of any database or file system of the apparatus.
A user may be a person, a program or an apparatus This application is a continuation of application Ser. 5 desiring to access stored data objects. According to one No. 08/74690, filed on Jun. 10, 1993, which is a continu- feature, a key associated with each located data object is ation of application Ser. No. 07/735393, filed on Jul. 24, returned to the user. The search criteria may identify 1991, both abandoned. single-data object or multiple-data object. Another fea
_ ture enables multiple-data objects to be organized in a
CROSS-REFERENCE TO RELATED 10 vjrtual directory to facilitate subsequent data object
Related subject matter is disclosed in my other appli- „„„„ _ ,
cation filed concurrently herewith and assigned to the BRIEF DESCRIPTION OF THE DRAWING
same assignee hereof: U.S. patent application Ser. No. In the drawing
07/735394 entitled "Method and Apparatus for Parsing 15 FIG. 1 is a block diagram of a client/server network
Extended File Names in an Operating System", now including a server computer in which the present inven
abandoned. tion may be utilized;
1. Technical Field FIG. 2 shows a logical and physical structure of a file The present invention relates to a computer system and a file system;
and, more particularly, to the accessing of a file system 20 FIG. 3 defines various terms useful in describing the
thereof. present invention;
2. Background of the Invention FIGS. 4 and 5 illustrate a flow chart describing variNetworks, such as local area networks (LANs), now ous operating features of the present invention;
enable personal computers (PCs) (typically referred to FIG. 6 shows an illustrative flow chart for impleas clients) to share resources, such as disk storage and 25 menting a single-object look-up criterion; printers, typically located at a host or server. These FIG. 7 shows an illustrative flow chart for impletypes of networks are generally referred to as client- menting a multi-object look-up criterion; and /server networks. In such client/server networks com- FIG. 8 illustrates a logical structure of a directory, mon databases required by the clients are also typically T^cc-dtd-tmtm stored at the server location. To enable clients to access 30 mtjH LfcV hL OfcisCKlP 1 ION the various common databases usually requires the use In the following description, each item or block of of one or more database management systems (DBMS) each figure has a reference designation associated thereat the server location. Moreover, to enable a client with, the first number of which refers to the figure in access to one of the common databases also requires which that item is first located (e.g., 110 is located in that each client have the DBMS access software. Un- 35 FIG. 1 and step 439 is located in FIG. 4). fortunately, the various DBMS access software re- Shown in FIG. 1 is a block diagram of an illustrative quired at a client location utilizes significant memory client/server system or network in which the present space, is costly, and must periodically be administered invention may be utilized. The network includes a or updated. Moreover, when more than one type of server computer 100 connected to a plurality of client DBMS is required at a server location, because of the 40 workstations or computers 102, 103 via a local area types of database utilized or because of client needs or network (LAN) 104. Server computer 100, illustrapreferences, the problem becomes more severe. Thus, tively, provides the client computers 102, 103 shared there is a continuing need to improve client database access to data stored on hard disk 180. access arrangements in a practical, cost-effective man- In one illustrative arrangement, each of the one or ner. 45 more client computers 102,103 may be a personal computer (PC) which operates using the well-known MSDOS (g) operating system or OS/2 ® operating system. In accordance with one aspect of my invention, I (MS-DOS is a registered trademark of the Microsoft have solved the above-described problems by treating Corporation. OS/2 is a registered trademark of IBM), the common databases like files and directories of the 50 The LAN 104 may, illustratively, be the AT&T STARserver. Then using the network file sharing facilities, LAN system. The server computer 100 may, illustraalready available to each client of the network, each tively, be an AT&T 6386 WorkGroup System cornclient can remotely access the databases using the exist- puter running on UNIX (g) System V Release 4.0 opering file access system calls. In addition to client/server ating system. (UNIX is a registered trademark of UNIX network applications, my invention is utilized, more 55 System Laboratories, Inc.). The client PCs 102,103 and generally, to enable a user to access a computer-based server computer 100 may use the AT&T Starfile apparatus using file-access system calls. GROUP TM system software. This StarGROUP sysAccording to my invention, a computer-based file tem software allows MS-DOS and OS/2 client PCs to apparatus permits a real-time user-selectable search transparently share data files on a LAN. request of previously stored data objects using file ac- 60 The server computer 100 running the server program cess system calls which use search criteria other than a 123 on top of the UNIX operating system 120 can supfile-name-substring matching. Search criteria includes a port one or more large hard disks (e.g., 105) that can be criterion type and a criterion value which combination made available to client PCs 102 and 103 on the LAN is also referred to as a search criterion type/value pair. 104.
The file access system call includes a purported file 65 Software on the client computer 103 interacts with
name containing one or more non-file-name-substring- the server program 123 on the server computer 100 to
based search criteria. Using my non-file-name-sub- allow access to disk 180 by client program 110. Specifi
string-based search technique, a user can do look-up-by- cally, system calls referencing disk 180 are packaged
into request messages by the redirector 112 and transmitted to the server program 123 by the network software 113 (known in the art as netbios and protocol software) over the local area network 104. The server program 123 processes the request and sends a response 5 to the client computer 103.
A more detailed description of the operating aspects of the client/server interaction is described in the article entitled "DOS Server Program for UNIX Computers" by I. J. Heizer, published in AT&T Technology, Volume 10 4, Number One, 1989.
Server computer 100, hereinafter referred to as the computer-based file system, operates under control of a UNIX operating system 105, shown using a high-level architecture layer diagram. The layer diagram includes 15 a user level 120, a kernel level 130, and a hardware level 140. The user level 120 interfaces to clients (hereinafter users) 102, 103 via LAN 104 enabling access to the desired file stored in disk 180.
The user level 120 includes user programs 121 (such 20 as the server program) and libraries 122. The hardware level 140 provides the operating system 110 with basic services needed by computer 100. The kernel level 130 interacts directly with the hardware level 140 providing common services to user level 120 programs and insu- 25 lating them from hardware 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 independent of the underlying hard- 30 ware, it is easy to move them between UNIX systems running on different hardware. The general description of the well-known operation of a UNIX operating system is derived from Chapter 2 of the book entitled "The Design of the UNIX Operating System" by Maurice J. 35 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 interface 131 converts user program calls into UNIX system 40 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 well-known manner. The set of system calls includes those that interact with the file system driver 132 and 45 those that interact with the process control subsystems 133. The file system driver 132 manages files, 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 50 open a file for reading or writing), close, read, write, stat (query the attributes of a file), chown (change the record of who owns the file) and chmod (change the access permissions of a file). The file system driver 132 accesses file data using a buffer 136 that regulates data 55 flow between the kernel and secondary storage devices. The buffering mechanism interacts with block I/O device 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 60 devices 141 are random access storage devices; alternatively, 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 65 system also interacts directly with "raw" or character I/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. The file system driver 132 and the process control subsystem 133 interact when loading a file into memory for execution. The process control subsystem 133 reads executable 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 process), exit (finish executing a process), wait (synchronize process execution with the exit of a previously forked process), brk (control the size of memory allocated to a process), and signal (control process response to extraordinary events).
With joint reference to FIGS. 1, 2 and 3 we describe an overview of a file system. Every file is named by one or more path names, 310. A path name, as shown in 310, includes file names (e.g., home) separated by delimiters (/). File names may be any of the types shown in 330. The internal representation of a file is given by an inode, 200, which contains a description of the disk layout of 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 map into 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 one file name component at a time, checks that the process has permission to search the directories in the path, and eventually 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 name starts with a slash character ("/") and specifies that the path name is relative to the "root" of the file system tree. Following the branches that lead to successive component names of the path name "/home/jqp/memoirs" designates a full path name while "/jqp/memoirs" does not. A path name does not have to 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" designates the file whose full path name is "/home/Bin".
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-memory inode table when manipulating 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 more file systems. A file system 220 is organized as a sequence of logical blocks, each containing 512, 1024,2048, or any convenient multiple of 512 bytes, depending on the system implementation. Multiples of 512 are used by convention and there is no intrinsic reason to use 512 byte blocks.
A physical file system may have the physical structure illustrated by 220 of FIG. 2. The boot block 221 (only on some file systems) occupies the beginning of a file system, typically the first disk sector, and may contain the bootstrap code that is read into the machine to