Extensible object-oriented file system

Description Submit all comments and votes

FIELD OF INVENTION

The present invention relates to file systems for computer operating systems. Specifically the present invention relates to an object-oriented file system.

BACKGROUND OF THE INVENTION

As will be understood by those skilled in the art, Object-Oriented Programming (OOP) techniques involve the definition, creation, use and destruction of "objects". These objects are software entities comprising data elements and routines, or functions, which manipulate the data elements. The data and related functions are treated by the software as an entity that can be created, used and deleted as if it were a single item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.

A full discussion of the object-oriented terms, notation and diagrams used in this disclosure is provided in "Object-Oriented Analysis and Design", edited by Grady Booch, and published by Benjamin Cummings, 1994. A brief overview of the Booch notation is shown in FIG. 5 with a class 22 being denoted by an amorphous blob, and a utility procedure 24 by a shadowed amorphous blob. A class category 26 is denoted by a rectangle, and contains a collection of related classes. A parameterized class 28 is denoted by an amorphous blob with a rectangle for the formal arguments 30, and an instantiated parameterized class 32 is denoted by an amorphous blob with a rectangle for the actual arguments 34. Relationships between the classes are denoted by an association line 36, inheritance arrow 38, "has a" solid circle line 40, and "uses" open circle line 42. Links between calling 43 and called 45 objects are denoted by an order:message arrow 44 and an object/value open circle arrow 46. Also shown is the symbols for denoting class properties 48 and the naming convention 50. The visibility of the called object 45 in relation to the calling object 43 is depicted by the letters G, P, F, and L, enclosed in a square 51 and representing Global, Parameter, Field ("part of" relationship), and Local respectively.

Provided bellow are definitions of some object oriented terms used in this disclosure:

base class the most abstract class of a framework from which all other classes are derived.

super class a class from which other classes are derived.

subclass a class that is derived from one or more super classes.

abstract class A class that defines abstract behavior and is used only as a super class for other subclasses, where the subclasses implement the abstract behavior. No instances are derived from an abstract class.

pure virtual method A method of an abstract class that must be overridden and implemented in a subclass.

concrete class A class that is complete in its implementation and may therefore have instances. A concrete class can also be a super class to other subclasses.

primitive type A data simple data type such as an integer, unsigned integer, long, character, etc.

extended type A complex data type such as an object.

Objects are defined by creating "classes" which are not objects themselves, but which act as templates that instruct the compiler how to construct an actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An object is actually created in the program by means of a special function called a "constructor" which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct the object. Likewise objects are destroyed by a special function called a "destructor". Objects may be used by manipulating their data and invoking their functions.

The principle benefits of object-oriented programming techniques arise out of three basic principles; encapsulation, polymorphism and inheritance. More specifically, objects can be designed to hide, or encapsulate, all, or a portion of, the internal data structure and the internal functions. During program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are considered "private" or for use only by the object itself. Other data or functions can be declared "public" or available for use by other programs. Access to the private variables by other programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the "outside" world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.

Polymorphism is a concept which allows objects and functions which have the same overall format, but which work with different data, to function differently in order to produce consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, during compilation, the C++ compiler will determine which of the three functions is actually being used by examining the variable types. The compiler will then substitute the proper function code. Polymorphism allows similar functions which produce analogous results to be "grouped" in the program source code to produce a more logical and clear program flow.

The third principle which underlies object-oriented programming is inheritance, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes (and the objects which are later created from them) as related. Specifically, classes may be designated as subclasses of other base classes. A subclass "inherits" and has access to all of the public functions of its base classes just as if these function appeared in the subclass. Alternatively, a subclass can override some or all of its inherited functions or may modify some or all of its inherited functions merely by defining a new function with the same form (overriding or modification does not alter the function in the base class, but merely modifies the use of the function in the subclass). The creation of a new subclass which has some of the functionality (with selective modification) of another class allows software developers to easily customize existing code to meet their particular needs.

Although object-oriented programming offers significant improvements over other programming concepts, program development still requires significant outlays of time and effort, especially if no pre-existing classes are available for modification. Consequently, a prior art approach has been to provide a program developer with a set of pre-defined, interconnected classes which create a set of objects and additional miscellaneous routines that are all directed to performing commonly-encountered tasks in a particular environment. Such pre-defined classes and libraries are typically called "application frameworks" and essentially provide a pre-fabricated structure for a working application.

For example, an application framework for a user interface might provide a set of pre-defined graphic interface objects which create windows, scroll bars, menus, etc. and provide the support and "default" behavior for these graphic interface objects. Since application frameworks are based on object-oriented techniques, the pre-defined classes can be used as base classes and the built-in default behavior can be inherited by developer-defined subclasses and either modified or overridden to allow developers to extend the framework and create customized solutions in a particular area of expertise. This object-oriented approach provides a major advantage over traditional programming since the programmer is not changing the original program, but rather extending the capabilities of the original program. In addition, developers are not blindly working through layers of code because the framework provides architectural guidance and modeling and, at the same time, frees the developers to supply specific actions unique to the problem domain.

There are many kinds of application frameworks available, depending on the level of the system involved and the kind of problem to be solved. The types of frameworks range from high-level application frameworks that assist in developing a user interface, to lower-level frameworks that provide basic system software services such as communications, printing, file systems support, graphics, etc. Commercial examples of application frameworks include MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXT Step App Kit (NEXT), and Smalltalk-80 MVC (ParcPlace).

While the application framework approach utilizes all the principles of encapsulation, polymorphism, and inheritance in the object layer, and is a substantial improvement over other programming techniques, there are difficulties which arise with the prior art application frameworks. Typically, application frameworks generally consist of one or more object "layers" on top of a procedure based operating system and even with the flexibility of the object layer, it is still often necessary to directly interact with the underlying operating system by means of awkward and inefficient procedure calls. In the same way that an application framework provides the developer with prefab functionality for an application program, a system framework, such as that included in a preferred embodiment, can provide a prefab functionality for system level services which developers can modify or override to create customized solutions, thereby avoiding the procedural calls necessary with the prior art application frameworks. For the commercial or corporate developer, systems integrator, or OEM, this means all of the advantages that have been illustrated for a framework, such as MacApp, can be leveraged not only at the application level for such things as text and user interfaces, but also at the system level, for services such as printing, graphics, multi-media, networking, I/O, and, as described herein, file systems.

A major part of computer operating systems is the system responsible for handling information stored in files. There are file systems designed for single processor systems such as Macintosh Hierarchical File System (HFS) and MS-DOS, or multiple processor distributed file systems such as AppleShare, Sun Network File System (NFS), or UNIX file system. A distributed file system is normally a super set of a single processor file system, that is, a distributed file system normally has all the features and capabilities of a single processor system except that it is distributed over several computers using a n