JP2003527659A - Internet file system - Google Patents

Abstract

(57) [Summary] The present invention provides a technique for accessing data stored in a database. According to one technique, an application makes one or more calls to an operating system to access a file. The operating system includes routines that implement an operating system file system. One or more calls are made to those routines that implement the operating system file system. In response to one or more calls, one or more database commands are issued to a database server that manages the database. The database server executes the database commands to search for data in the database. A file is generated from the data and provided to the application.

Description

Detailed Description of the Invention

[0001]

[Reference to priority claims and related applications]

This application is referred to by Eric Sedlar in "Internet File System (" Internet File System ", which is incorporated by reference as if fully set forth herein).
Claims its domestic priority under 35 USC 119 (e) regarding prior US provisional patent application serial no. 60 / 147,538 filed August 5, 1999 entitled "File System") " .

[0002] The present application is entitled "Hierarchy for Accessing Information Hierarchically Organized in Relational Systems," by Eric Sedlar, the entire text of which is incorporated by reference as if fully set forth herein. Indexing ("Hierarchical Indexing for Accessing Hie
"Rarchically Organized Information in a Relational System"). "

This application is referred to as "File System that Supports Transactions" by Eric Sedlar, the entire text of which is incorporated by reference as if fully set forth herein. Related to U.S. Patent Application Serial No. 09 / 571,496, filed May 15, 2000.

The present application is described by Eric Sedlar in "Stored Queries Directory", which is incorporated by reference in its entirety as if fully set forth herein.
No. 09 / 571,060, filed May 15, 2000, entitled "ry Directories") ".

This application is described by Eric Sedlar in “Event Notification System Tied to a File System” by Eric Sedlar, which is incorporated by reference in its entirety as if fully set forth herein. US Patent Application Serial No. 09 / 571,036, filed May 15, 2000, entitled "File System") ".

This application is referred to by Eric Sedlar in "Object File System with Typed Files," which is incorporated by reference in its entirety as if fully set forth herein. 20) entitled ")"
Related to U.S. Patent Application Serial No. 09 / 571,492, filed May 15, 2000.

The present application is referred to by Eric Sedlar in “On-the-fry Format Conversion”, which is incorporated by reference in its entirety as if fully set forth herein.
US Patent Application Serial No. 09 / 571,568, filed May 15, 2000, entitled "Ly Format Conversion") ".

This application is described by Eric Sedlar and Michael J. Roberts in “Versioning in Internet File System”, the entire text of which is incorporated by reference as if fully set forth herein.
US Patent Application Serial No. 09/5 filed May 15, 2000 entitled "m") "
71,696.

The present application is entitled “Multi-Model Access to Data (“ Multi-Mo ”by Eric Sedlar, which is incorporated by reference in its entirety as if fully set forth herein.
"Access to Data") "filed May 15, 2000 and is related to U.S. Patent Application Serial No. 09 / 571,508.

[0010]

FIELD OF THE INVENTION

The present invention relates generally to electronic file systems, and more particularly to systems that implement operating system file systems using database systems.

[0011]

BACKGROUND OF THE INVENTION

Humans tend to classify information into categories, and the categories into which information is classified are typically configured in some hierarchical relationship with each other. For example,
Individual animals belong to species, species belong to genus, genus belongs to family, family belongs to eye, eye belongs to class.

With the advent of computer systems, such a hierarchical structure (hierarchical o
The storage technology of electronic information that largely reflects the human desire for rganization has been developed. Conventional operating systems provide, for example, file systems that use a hierarchy-based composition principle. Specifically, in a typical operating system file system (“OS file system”), directories are arranged in a hierarchy and documents are stored in those directories. Ideally, the hierarchical relationship between directories reflects some intuitive relationship between the meanings assigned to those directories. Similarly, if each document is stored in a directory, it should ideally be stored based on some intuitive relationship between the content of that document and the meaning assigned to the directory in which the document is stored. is there.

FIG. 1 illustrates a typical mechanism used by software applications that create and use files (such as word processors) to store the files in a hierarchical file system. Referring to FIG. 1, operating system 1
04 exposes an application programming interface (API) to the application 102. The API so opened allows the application 102 to call routines provided by its operating system. Hereinafter, the part of the OS API related to the routine that realizes the OS file system will be referred to as the OS file API. The application 102 calls a file system routine via the OS file API to retrieve data and store it on the disk 108. The operating system 104 is a device driver 1 that controls access to the disk 108.
06 is called to retrieve the file from the disk 106 or store the file in the disk 106.

The OS file system routine realizes a hierarchical structure of the file system. For example, OS file system routines maintain information about hierarchical relationships between files and give application 102 access to files based on their location in the hierarchy.

In contrast to the hierarchical structure of electronic information, a relational database (relational dat)
abase) stores information in a table of matrices. Each row is identified by a unique RowID. Each column represents a record's attributes, and each row represents a particular record. Retrieval of data from a database is done by submitting a query to a database management system (DBMS) that manages the database.

FIG. 2 illustrates a typical mechanism used by database applications to access information in a database. Referring to FIG. 2, the database application 202 interacts with the database server 204 through an API (“database API”) provided by the database server 204. The API thus opened allows the database application 202 to access the data using queries constructed in the database language supported by the database server 204. Structured Query Language is one of the languages supported by many database servers.
guage, SQL). The database server 204 presents to the database application 202 all the data as if it were stored in a row in the table. However, transparent to the database application 202, the database server 204 actually interacts with the operating system 104 to store the data as files in the OS file system. The operating system 104 makes a call to the device driver 106 to retrieve the file from the disk 108 or retrieve the file from the disk 10.
It is memorized in 8.

Each storage system has its advantages and limitations. The hierarchically organized storage system is simple, intuitive, easy to implement, and is the standard model used by most application programs. Unfortunately, however, the simplicity of this hierarchical organization cannot provide the support required for complex data retrieval operations. For example, it may be necessary to inspect the contents of all directories to find all documents created on a particular day with a particular filename. Hierarchical organization cannot facilitate the search process because all directories must be searched.

Relational database systems are well suited for storing large amounts of information and accessing data very flexibly. For hierarchically organized systems, even data that meets complex search criteria can be easily and efficiently retrieved from relational database systems. However, the query is formulated (formulat
The process of e) presenting to the database server is less intuitive than simply going through the hierarchy of directories, and is beyond the technical comfort of many computer users.

At this time, application developers want the data created by those applications to be accessible through the hierarchical file system provided by the operating system, or more complex queries provided by the database system. You will be asked to choose whether you want it to be accessible through the interface. In general, for applications that do not require the complex search capabilities of database systems, they are designed to store their data using the more general and simpler hierarchical file system provided by the operating system. in this case,
While both designing and using the application are simplified, they limit the flexibility and power with which they can access that data.

On the other hand, when complicated search capability is required, the application
It is designed to access those data using the query mechanism provided by the database system. This gives you more flexibility and power to access your data, but at the same time increases the complexity of your application.
It increases from both the designer's perspective and the user's perspective. In addition, the existence of a database system is required, which adds additional cost to application users.

In view of the above, it is clearly desirable for an application to be able to access data using a relatively simple OS file API. It is further desirable to be able to access the same data using a more powerful database API.

[0022]

[Outline of the Invention]

Techniques are provided for accessing the data stored in the database. According to one technique, an application makes one or more calls to an operating system to access a file. The operating system includes routines that implement the operating system file system. The one or more calls are made to a routine that implements the operating system file system. In response to the one or more calls, one or more database commands are issued to the database server managing the database. The database server executes the database command to retrieve data from the database. A file is created from the data,
Given to the application.

The present invention is described below for purposes of illustration and not limitation with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same elements.

[0024]

Detailed Description of the Preferred Embodiments

Database API and OS file system A for the same data set
Methods and systems are provided that allow access through a variety of interfaces including PIs. For the purposes of explanation, numerous specific details are set forth below for the purpose of a thorough understanding of the present invention, but those skilled in the art will appreciate that the present invention may be practiced without these specific details. It will be clear to get. In other instances, well-known structures and devices are shown in block diagrams in order not to unnecessarily obscure the present invention.

Architectural Overview FIG. 3 is a block diagram representing the architecture of a system 300 implemented in accordance with one embodiment of the present invention. Similar to the system shown in FIG.
It includes a database server 204 that provides a database API through which the database application 312 can access data managed by the database server 204. From the perspective of all entities accessing data managed by the database server 204 through the database API, the data managed by the database server 204 may be queried using a database language supported by the database server 204 (eg, SQL). Stored in a table. Transparent to these entities, database server 204 stores this data on disk 108. According to one embodiment, the database server 204 is
Allowing data to be stored directly to disk avoids the overhead associated with the OS file system of operating system 104,
Implement disk management logic. Therefore, the database server 204 uses (1
Data is stored on disk either by calling the OS file system provided by operating system 104 or (2) bypassing operating system 104 by storing the data directly on disk. obtain.

Unlike the system of FIG. 2, system 300 provides a translation engine 308, which is a database that translation engine 308 issues to I / O commands received from operating systems 304a and 304b to database server 204. Convert to command. When an I / O command requests storage of data, translation engine 308 issues a database command to database server 204, causing the data to be stored in a relational table managed by database server 204. When an I / O command requests retrieval of data, translation engine 308 issues a database command to database server 204 to retrieve the data from a relational table managed by the database server. Then translation engine 3
08 provides the data thus retrieved to the operating system which issued the I / O command.

To the operating systems 304a and 304b, the fact that the data communicated to the translation engine 308 is ultimately stored in relational tables managed by the database server 204 is transparent. Because it is transparent to operating systems 304a and 304b, it is also transparent to applications 302a and 302b running on the platform containing those operating systems.

For example, assume that the user of application 302a selects the "save file" option provided by application 302a. The application 302a makes a call through the OS file API to cause the operating system 304a to save the file. The operating system 304a issues an I / O command to the translation engine 308 to store the file. In response, translation engine 308 issues one or more database commands to database server 204, causing database server 204 to store the data contained in the file in a relational table maintained by database server 204. The database server 204 may store this data directly on disk or the operating system 104.
To store the data in the OS file system provided by the operating system 104. When the database server 204 calls the operating system 104, the operating system 104 responds by sending a command to the device driver 106 to store the data on the disk 108.

As another example, the user of the application 302 a may use the application 302
Let us assume that the option "load file" given by a is selected. The application 302a makes a call through the OS File API to cause the operating system 304a to load the file. The operating system 304a issues an I / O command to the translation engine 308 to load the file. The translation engine 308 issues one or more database commands to the database server 204, causing the database server 204 to retrieve the data that comprises the file to be retrieved from the relational tables held by the database server 204. Database server 2 while searching for data
04 may search the data directory or may call the operating system 104 to retrieve the data from the OS files on the disk 108. Once the data is retrieved, the desired file is "built" from the retrieved data. Specifically, the retrieved data is in the format predicted by the application 302a that requested the file. The file thus constructed is transmitted to the application 302a through the translation engine 308 and the operating system 304a.

Many new features are incorporated into system 300. The following sections describe these features in more detail. However, it should be understood that the particular embodiments are used to illustrate these features and the invention is not limited to these particular embodiments.

OS File System Access to Associatively Stored Data According to one aspect of the invention, system 300 enables applications to access data stored in a database through a conventional OS file API. . That is, conventional applications designed to load files by calling the standard OS file API provided by the operating system can load files built on the fly from data stored in relational tables. become. Moreover, the fact that the data originates from the relational table is completely transparent to the application.

For example, if the database application 312 is the database server 20
Suppose you issue a database command that inserts a row of data into a table in the database held by 4. Once that line is inserted, a relatively simple OS file API provided by operating system 304a.
Applications that are designed only to access data using
02a sends a command "open file" to the operating system 30.
Depart at 4a. In response, operating system 304a issues an I / O command to translation engine 308, which in turn responds by issuing one or more database commands to database server 204. The database server 204 causes the database server 204 to retrieve the row inserted by the database application 312 by executing a database command (typically in the form of a database query). A file of the file type predicted by the application 302a is constructed from the data contained in the row, and the file thus constructed is returned to the application 302a through the translation engine 308 and the operating system 304a.

The system 300 not only allows an application that only supports conventional OS file system access to load data that has been associated and stored, but that an application that supports only conventional OS file system access does not. The information provided can be accessed by database applications using conventional query techniques. For example, it is assumed that the application 302a calls the OS to save the created file.
The "save file" command is communicated to database server 204 through operating system 304a and translation engine 308. The database server 204 receives a "save file" command in the form of a database command issued by the translation engine 308, and the data contained in the file is stored in one or more databases contained in the database managed by the database server 204. Store in one or more rows of the table. Once the data is stored in the database in that manner, the database application 312 can issue a database query to the database server 204 to retrieve the data from the database.

Emulating the OS File System Configuration in the Database As described above, the calls to the file system routines of operating systems 304a and 304b ultimately result in database commands issued by translation engine 308 to database server 204. Is converted to. According to one embodiment of the invention, the process of performing these conversions is simplified by emulating within the database server 204 the characteristics of the file system implemented by the operating systems 304a and 304b.

With respect to this configuration model, most operating systems implement a file system that organizes files in a file hierarchy. Thus, the OS file system calls made by applications 302a and 302b will typically identify a file in terms of its location within the OS file hierarchy. To simplify the conversion of such calls into the corresponding database calls, a mechanism is provided to emulate a hierarchical file system within the database system concerned. One such mechanism was filed by Eric Sedlar on February 18, 1999, entitled "HIERARCHICAL INDEXING for accessing hierarchically structured information in systems of interest. FOR ACCESSING HIERARCHICALLY O
RGANIZED INFORMATION IN A RELATIONAL SYSREM) ", which is fully described in US patent application Ser. No. 09 / 251,757, the entire contents of which are incorporated herein by reference.

Specifically, the “HIERARCHICAL INDEXING” application includes creating, maintaining, and using hierarchical indexes to efficiently access information in relevant systems based on pathnames, Techniques for emulating a hierarchically configured system are described. Each item that has some children in the emulated hierarchical system has an index entry in its index. The index entries in the index are linked together in a manner that reflects the hierarchical relationships among the items associated with these index entries.
Specifically, if a parent-child relationship exists between items associated with two index entries, the index entry associated with the parent item has a direct link to the index entry associated with that child item.

Consequently, resolution of the pathname is performed by following a direct link between index entries associated with items in the pathname according to a sequence of filenames in the pathname. . By using an index whose index entries are linked in this manner, the process of accessing items based on their pathnames is significantly accelerated, and the number of disk accesses made during that process is significantly reduced.

Hierarchical Index A hierarchical index consistent with the present invention, as specified by a pathname,
Supports hierarchical system pathname-based access methods, moving from parent items to their children. According to one embodiment, a hierarchical index consistent with the principles of the present invention employs an index entry that includes the following three fields. RowI
D, FileID, and Dir_entry_list (stored as an array).

FIG. 5 shows a tier index 510 that can be used to emulate a tiered storage system in a database. FIG. 6 shows the particular file hierarchy structure that the hierarchy index 510 emulates. FIG. 7 shows a file table 710 used to store the files shown in FIG. 6 in a relational database.
Indicates.

The hierarchical index 510 is a table. The RowID field contains a system-generated ID that identifies the disk address that allows the database server 204 to locate the row on disk. According to this relational database system, the RowID can be an implicitly defined field used by the DBMS to locate the data stored on the disk drive. The FileID field of the index entry stores the FileID of the file associated with this index entry.

According to one embodiment of the invention, the hierarchical index 510 stores only index entries for items that have children. Thus, in terms of an emulated hierarchical file system, the only items that have index entries in the hierarchical index 510 are directories that are parents to other directories and / or directories that are currently storing documents. Those items that have no children (eg Example.doc, Access, App in Figure 6
l, App2, App3) are preferably not included. The Dir_entry_list field of the index entry for a given file stores an "array entry" for each of the child files of the given file in an array.

For example, index entry 512 is a Windows® directory 614.
Against. Word directory 616 and Access directory 620
Is a child of the Windows® directory 614. Therefore, the Dir_entry_list field of the index entry 512 for the Windows® directory 614 includes an array entry for the Word directory 616 and an array entry for the Access directory 620.

According to one embodiment, the specific information that the Dir_entry_list field stores for each child includes the child's file name and the child's FileID. For children that have their own entry in the hierarchical index 510, the Dir_entry_list field also stores the RowID of the child index entry. For example, the Word directory 616 has its own entry in the hierarchical index 510 (entry 514). Therefore, the Dir_entry_list field of the index entry 512 is the name (“Word”) of the directory 616, and the RowID (“Y3”) of the index entry for the directory 616 in the hierarchical index 510.
, And the FileID (“X3”) of the directory 616. As will be explained in more detail, the information contained in the Dir_entry_list field makes access to information based on pathnames faster and easier.

Some major principles of hierarchical indexes are: The Dir_entry_list information of index entries for a given directory is kept together as few disk blocks as possible. This is because the most frequently used file system operations (path name derivation, directory listing) will have to look at many entries in a directory whenever it is referenced. Is. In other words, a directory entry should have a high degree of locality to reference, since when a particular directory entry is referenced, other entries in the same directory are also often referenced.

The information stored in the index entries of the hierarchical index must be kept to a minimum to fit the maximum number of entries in a particular disk block. Grouping directory entries together into array means that do not require repeating keys that identify the directories in which they are included will result in all entries in the directory sharing the same key.

The time required to derive the path name should be proportional to the number of directories in the path, not the total number of files in the file system. This allows the user to keep frequently accessed files at the top of the file system tree where access times are low.

All of these elements reside in a typical file system directory structure, such as the UNIX system of inodes and directories. By using a hierarchical index as described here, their purpose and structure that the relational database understands and can query are matched, and the database server is different from the one used to derive the pathname. It becomes possible to perform an ad hoc search of a file in this mode. To do this, one has to use the database concept of an index. That is, subordinate information (file data in this case) placed in a separate data structure in another manner designed to optimize access through a particular method (in this case, derivation of pathnames in a hierarchical tree). Is a duplicate of the part.

Using Hierarchical Index How the hierarchical index 510 can be used to access a file based on the pathname of the file will now be described with reference to the flowchart of FIG. For purposes of explanation, assume that document 618 is accessed via its pathname. The path name of this file is / Windows (R) / Word / Exam
ple.doc, which will be referred to as "input path name" hereinafter. Given this pathname, the pathname derivation process begins by locating in the hierarchical index 510 the location of the index entry for the first name in this input pathname. For some file systems, the first name in the pathname is the root directory. Therefore, the pathname derivation process for locating a file in the emulated file system begins by locating the index entry 508 of the root directory 610 (step 800).
Since all pathname derivation operations begin by accessing the root directory's index entry 508, the data indicating the location of the index entry for the root directory 610 (index entry 508) is the root directory's index entry at the beginning of every search. It may be kept at a convenient location outside the hierarchical index 510 to quickly locate 508.

Once the location of the index entry 508 for the root directory 610 is located, the DBMS determines if there are any filenames in the input pathname (step 802). If there are no more files in the input pathname, control proceeds to step 820 and the File stored in index entry 508.
The ID is used to look up the root directory entry in the file table 710.

In this example, the file name “Windows (R)” follows the root directory symbol “/” in the input path name. Therefore, control proceeds to step 804. In step 804, the next file name (eg, "Windows (R)" is selected from the input pathnames. In step 806, the DBMS causes index entry 508.
Look at the Dir_entry_list column of to locate the array entry for the selected file name.

In this example, the file name following the root directory in the input path name is “Windows (R)”. Therefore, in step 806, the file name "Windo
Dir_entry of index entry 508 for the ws (R) ”array entry
It involves searching _list. If the Dir_entry_list does not contain an array entry for the selected filename, control proceeds from step 808 to step 810 where an error is generated indicating that the input pathname is invalid. In this example, the Dir_entry_list of index entry 508 contains a "Windows (R)" array entry. Therefore, control proceeds from step 808 to step 82.
Move on to 2.

The information in Dir_entry_list of index entry 508 indicates that one of the children of root directory 610 is actually a file named “Windows (R)”. In addition, the Dir_entry_list array entry contains the following information for this child: That is, this is an index entry that matches RowIDY2, and this FileID is X2.

At step 822, it is determined whether the input path name still has any file name. If there are no more filenames, control transfers from step 822 to step 820. In this example, "Windows (R)" is not the last file name, so control transfers to step 824 instead.

Since “Windows (R)” is not the last file name in the input path, Dir_entr
The FileID information contained in y_list is not used during this path derivation operation. Rather, the Windows (R) directory 614 is only part of the identified path and not the target, so the file table 710 is not examined at this point. Instead, in step 824, index entry 508 Dir_ent
The RowID (Y2) for "Windows (R)" found in ry_list is used to locate the index entry for the Windows (R) directory 614 (index entry 512).

Looking at the Dir_entry_list of index entry 512, the system
The next file name in the input path name is searched (steps 804 and 806).
In this example, the file name "Word" is in the input path and the file name is "Windows (R)".
Followed by. Therefore, the system searches the Dir_entry_list of index entry 512 for the "Word" array entry. Such an entry exists in the Dir_entry_list of the index entry 512, and the "Windows (
R) ”actually has a child named“ Word ”(step 808).
). In step 822, it is determined that there is still a file name in the input path,
Therefore, control proceeds to step 824.

Upon finding an array entry for “Word”, the system reads the information in that array entry and finds that an index entry for Word directory 616 is found at RowIDY3 in hierarchical index 510 and belongs to Word directory 616. It is determined that the particular information is found at row X3 in file table 710. The file table 710 is not consulted because the word directory 616 is only part of the specified path and not the target. Instead, the system uses the RowID (Y3) to create the Word directory 61.
Locate index entry 514 for 6 (step 824)
.

At RowIDY3 of hierarchy index 510, the system finds index entry 514. In step 804, the next file name "Example.doc" is selected from the input path names. In step 806, the Dir_entry_list of index entry 514 is searched to find an array entry for "Example.doc" (step 808), which is "Example.doc" Wor.
d Indicates that the directory 616 is a child. This system also uses Example.doc
Does not have any indexing information in the hierarchical index 510, and uses the FileIDX4 to provide specific information about Example.doc in the file table 7
I also find that I can find it in 10. Since Example.doc is the target file to be accessed (ie the last filename in the input path), control transfers to step 820, where the system uses FileIDX4 to access the appropriate row in file table 710. , And the file body (BLOB) stored in the body column of that row is extracted. In this way, the Example.doc file is accessed.

Only the hierarchical index 510 was used to access this file. No table scan required. If the size of the block and the length of the file name are typical, then at least 600 directory entries will fit in one disk block, a typical directory has less than 600 entries. That is, the list of directory entries in a given directory will typically fit in a single block. In other words, each index entry of hierarchical index 510, which includes the entire Dir_entry_list array of index entries, will typically fit into a single block and thus can be read in a single I / O operation.

In moving from an index entry in the hierarchical index 510 to an index entry, it may be necessary to do some disk access if the various index entries in the index reside in different disk blocks. However, if each index entry fits perfectly into a single block, the number of disk accesses will be less than or equal to the number of directories in the path. Even if the average index entry size does not fit into a single disk block, the number of disk accesses per directory is a term and does not increase with the total number of files in the file system.

The above description of the techniques for emulating the hierarchical features owned by some file systems is merely exemplary. Other techniques may also be used to emulate the hierarchical characteristics of some file systems and protocols. Furthermore, some protocols may not even possess hierarchical features.
As such, the present invention is not limited to any particular technique for emulating the hierarchical characteristics of some protocols. Furthermore, the invention is not limited to protocols that are hierarchical in nature.

Emulating Other OS File System Features in Databases Besides the hierarchical organization of OS file systems, another feature of most OS file systems is that they hold specific system information about the files they store. It is that you are. According to one embodiment, this OS file system feature is also emulated within the database system. Specifically, the translation engine 308 stores the “system” data of a file in a file table (eg, the file table 71) managed by the database server 204.
0) Issue a command to store in a certain line. According to one embodiment, all or most of the contents of the file are stored in a large binary object (B
LOB). In addition to the BLOB column, the file table further includes a column for storing attribute values corresponding to those implemented in the OS file system. Such attribute values include, for example, the owner or creator of the file, the creation date of the file, the last modified data of the file, the hard link to the file, the file name, the file size, and the file type.

When the translation engine 308 issues database commands to cause the database server 204 to perform some file operation, those database commands are statements that cause the attributes associated with the file associated with that operation to be appropriately modified. including. For example, in response to inserting a new row in the file table for the newly created file, translation engine 308 issues a database command,
(1) Store a value that indicates to the user who created the file in the "owner" column of the row, and (2) store a value that indicates the current date in the "creation date" column of the row. , (3) Store the value indicating the current date and time in the “Last changed” column, and (4) B
A value indicating the size of the LOB is stored in the "size" column. In response to subsequent operations in this file, the values in these fields are changed as required by those operations. For example, the translation engine 30
8 issues a database command that modifies the contents of a file stored on a particular line, the translation engine 30
8 issues a database command that updates the "last modified" value for that particular row. In addition, if the change changes the file size, translation engine 308 also issues a database command to update the "size" value for that particular row.

Another feature of most OS file systems is the ability to provide security on a per file basis. For example, Windows (R) NT, VMS and UNI
Some versions of X (R) maintain an access control list that indicates the rights that various entities have for each file. According to one embodiment of the invention, this OS file system feature is emulated in the database system by maintaining a "security table", each row of which is similar to an entry in the access control list. Including content. For example, a row in this security table has one column for storing values that identify files and another column for storing values that represent permission types (eg, read, update, insert, execute, change permission). And another field that stores a flag that indicates whether the permission was granted or not, and an owner field that stores a value that represents the owner of the permission for the file. The owner may be a single user identified by a user ID (userid) or a group identified by a group ID (groupid). For groups, one or more additional tables are used to map the group ID to the user IDs of members of the group.

Before issuing a database command to access a file stored in a file table managed by the database server 204, the translation engine 308 requests the file for which the user requesting access is identified. Issue a database command that verifies that you have permission to perform the type of access made. Such a pre-access database command retrieves data from the security table and determines whether the user requesting the access is permitted to execute the access. If the data so retrieved indicates that the user does not have the required permission, translation engine 308 does not issue a command to perform the requested operation. Instead, translation engine 308 returns an error message to the operating system from which the request originated. In response to this error message, the operating system will send to the application requesting access if the application attempts to access a file held in the operating system's OS file system without permission. Send the same OS error message as the one. Thus, the fact that data is stored in a relational database rather than the OS file system, even under error conditions, is transparent to the application.

Different operating systems store different types of system information about files. For example, one operating system may store the "archive" flag but not the icon information, and another may store the icon information and not the archive flag. The particular set of system data maintained by a database system implementing the techniques described herein may vary for each implementation. For example, database 20
4 may store all of the system data supported by the OS file system of operating system 304a.
Only some of the system data supported by the 04b OS file system can be stored. Alternatively, the database server may store all of the system data supported by both operating systems 304a and 304b, or operating systems 304a and 304.
Some of the system data supported by any one of b may be stored.

As shown in FIG. 3, the database server 204 stores files originating from a number of separate OS file systems. For example, operating system 304a may be different than operating system 304b, and both operating systems 304a and 304b may be different from operating system 104. The OS file systems 304a and 304b may have contrasting features. For example, OS file system 304a
May allow the file name to include the character "/", whereas OS file system 304b may not. According to one embodiment, in such a situation, translation engine 308 is configured to implement OS file system specific rules. Thus, when application 302a attempts to store a file that contains the character "/" in the filename, translation engine 308 issues a database command that causes database server 204 to perform that operation. On the other hand, when the application 302b attempts to store a file that contains the character "/" in the filename, translation engine 308 raises an error.

Alternatively, translation engine 308 may be configured to implement a single set of rules for all operating systems. For example, the translation engine 308 may find that the filename is invalid even in one operating system supported by the translation engine 308, even if the filename issued the command that specified the filename. A rule can be implemented that, even if valid, will cause an error.

Conversion of OS File System Calls to Database Queries OS file system calls make OS file system calls by constructing a mechanism for emulating OS file system features within the database system. It can be translated by the translation engine 308 into a database query without losing the functionality expected by the application. This OS file system call made by those applications is done through the OS file API provided by the operating system on which they are executing. For example, for a program written in the "C" programming language, a source code file entitled "stdio.h" is used to specify the interface of the OS file API of an operating system. Since this stdio.h file is included in the applications, these applications will know how to call the routine that implements the OS file API.

The particular routines that implement the OS file API may vary from operating system to operating system, but typically include routines for performing the following operations: Open file, read from file, write to file, seek in file, lock file, and close file. In general, the mapping of these I / O commands to relational database commands is: open file = start transaction, derive pathname and locate line containing file Write to file = read from file to update = Lock the selected file = Lock the row associated with the file = Seek into the file = Update the counter = Close the file = Complete the transaction (Windows (R) OS file system protocol writes the file data Expects the directory entry to be completed just before it is populated (other protocols do not). Expect to make the name of the file visible even before receiving the contents of the file, as described in more detail below. Some file systems do. In the context of these file systems, the "Open File" I / O command is used to start a transaction to write a name, complete a transaction to write a name, and start a transaction to write content. Correspond.

According to one embodiment, a counter is used to track the “current location” in the file. In the embodiment where the file is stored as BLOB, the counter is BLOB.
Can take the form of an offset from the beginning. When the "Open File" command is executed, a counter is created and set to a value indicating the execution start address of the BLOB in question. The BLOB counter is then incremented in response to data being read from or written to the BLOB. Seek operation
Update the counter to point to the location in the BLOB pointed to by the parameters of this seek operation. According to one embodiment, these operations were filed on October 31, 1997 by Nori et al. In "LOB Locator (
This is facilitated by the use of LOB locators as described in US patent application Ser. No. 08 / 962,482 entitled "LOB LOCATORS)", the entire contents of which are incorporated herein by reference.

In some operating systems, OS locks may continue even after closing a file. To emulate this feature, lockfile commands are translated into session lock requests. As a result, when "commit transaction" is performed in response to a command that closes this file, the lock on the row associated with that file is not automatically released. The lock thus established is released either explicitly in response to a command to unlock the file or automatically in response to the end of the database session in which the lock was acquired.

I / O Operation in Progress When a file is created, the directory in which the file is created is updated to indicate the existence of the file. In some OS file systems, changing the directory to point to a new file is accomplished before the new file is completely created. Some applications designed for those OS file systems make good use of that feature. For example, one application opens a new file with the first file handle,
You can proceed to write the data into the file. While the data is being written
The same application can open the file with a second file handle.

Emulating this feature in a database entails a special problem. This is because, in general, another transaction cannot see the changes made by that transaction until the database transaction completes. For example, assume that a first database transaction was initiated in response to a first "open" command. The first transaction updates the directory table to indicate that the file exists in a particular directory,
Then update the file table to insert the row containing the file. When a second database transaction is initiated in response to a second "open" command issued by the same application, the second database transaction will include changes to the directory table, new lines in the file table, Not visible until the first transaction completes.

According to one embodiment of the present invention, the ability to see a directory entry for a file that is in the process of being created is a transaction in the directory table that is separate from the transaction used to insert a row for that file into the file table. It is emulated in the database system by causing the updates to occur. Thus, in response to the first open command, translation engine 308
Issues a database command to (1) start the first transaction,
2) Change the directory table to indicate the existence of the new file, (3)
Complete the first transaction, (4) start the second transaction, (5) insert a row of this file into the file table, and (6) complete the second transaction. By committing the changes to the directory table separately from the changes to the file table, a third transaction initiated in response to the second open command is a directory transaction while an insert into the file table is still in progress. You can see the entries in the table. Second
If the transaction fails, then this directory will be left with no file contents, along with an entry for the file.

Translation Engine According to one embodiment of the invention, translation engine 308 is designed in two layers. These layers are shown in FIG. Referring to FIG. 4, translation engine 308 includes a protocol server layer and a DB file server 408 layer. The DB file server 408 allows applications to access data stored in the database managed by the database server 204 through an alternative API (referred to herein as the DB file API). DB
The file API combines aspects of both the OS file API and the database API. Specifically, the DB file API supports file operations similar to those supported by conventional OS file APIs.

However, unlike the OS file API, the DB file API incorporates the concept of a database API for transactions. That is, the DB file A
PIs allow applications to specify that a set of file operations is performed atomically. The advantages of having a transacted file system are described in more detail below.

DB File Server The DB file server 408 plays a role of converting a DB file API command into a database command. The DB file API commands received by the DB file server 408 may come from the protocol server layer of the translation engine 308, or are specifically designed to perform file operations by making calls through the DB file API. It may be directly from the application (eg application 410).

According to one embodiment, the DB file server 408 is object oriented. Thus, the routines provided by the DB file server 408 are invoked by the instantiation of an object and by calling the method associated with that object. In a certain implementation, the DB file server 4
08 defines a "transaction" object class that includes the following methods: Insert, save, update, delete, commit and rollback. The DB file API provides an interface that allows external entities to instantiate and use this transaction object class.

Specifically, when an external entity (eg, application 410 or protocol server) makes a call to the DB file server 408 and creates an instance of a transaction object, the DB file server 408 causes the database server 204 to start a new transaction. Send a database command. This external entity then calls the method of the transaction object. Calling a method results in a call to the DB file server 408. In response to this call, the DB file server 408 issues a corresponding database command to the database server 204. All database operations performed in response to a method invocation of a given transaction object are performed as part of the database transaction associated with this given transaction object.

Importantly, the method invoked for a single transaction object may involve multiple file operations. For example, the application 410 may interact with the DB file server 408 as follows. The application 410 creates an instance of the transaction object TXO1 by calling it through the DB file API. In response, the DB file server 408 issues a database command that initiates transaction TX1 within the database server 204. The application 410 calls the TXO1 update method to update the file F1 stored in the database managed by the database server 204. In response, DB file server 408 issues a database command that causes database server 204 to perform the requested update as part of transaction TX1. The application 410 calls the update method of TXO1 to update the second file F2 stored in the database managed by the database server 204. In response, DB file server 408 issues a database command that causes database server 204 to perform the requested update as part of transaction TX1. After this, the application 410 calls the TXO1 completion method. In response to this, the DB file server 408 changes the database server 204
Issue a database command to complete TX1. If the update to file F2 fails, the rollback method of TXO1 is called to roll back all the changes made by TX1, including the update of file F1.

Although the technique has been described herein with reference to a DB file server using transaction objects, other implementations are possible. For example, in the DB file server, objects can be used to represent files rather than transactions. In such an implementation, a file operation may be performed by invoking the method of the file object and passing to it data specifying the transaction in which the operation is to be performed. Therefore, the present invention is not limited to DB file servers that implement any particular set of object classes.

For purposes of illustration, the embodiment depicted in FIG. 4 uses a DB as the process executing external database server 204 that communicates with the database server 204 through the database API.
A file server 408 is shown. However, according to an alternative embodiment, the functionality of the DB file server 408 is incorporated into the database server 204. DB
Incorporating the file server 408 into the database server 204 reduces the amount of inter-process communication generated during use of the DB file system. The database server created by incorporating the DB file server 408 into the database server 204 thus provides two alternative APIs for accessing the data managed by the database server 204, namely DB file A.
Provides PI and database API (SQL).

Protocol Server The protocol server layer of the translation engine 308 is responsible for converting between specific protocols and DB file API commands. For example, the protocol server 406a sends the I / O command received from the operating system 304a to the DB file server 408 that sends the DB file AP.
Convert to I command. The protocol server 406a also translates DB file API commands received from the DB file server 408 into I / O commands that it sends to the operating system 304a.

In reality, there is no one-to-one correspondence between protocols and operating systems. Rather, many operating systems support more than one protocol, and many protocols are supported by more than one operating system. For example, a single operating system may provide unique support for one or more network file protocols (SMB, FTP, NFS), email protocols (SMTP, IMAP4), and web protocols (HTTP). Moreover, overlaps often occur between sets of protocols supported by different operating systems.
However, for purposes of illustration, a simplified environment is shown in which operating system 304a supports one protocol and operating system 304b supports another protocol.

I / O API As mentioned above, a protocol server is used to convert I / O commands into DB file commands. The interfaces between the protocol servers and their OS file system counterparts are comprehensively labeled I / O.
It is an API. However, the specific I provided by some protocol server
The / O API includes (1) the entity with which the protocol server communicates and (2
Both depend on how the protocol server is exposed to that entity. For example, operating system 304a is Microsoft Windows
(R) NT, and the protocol server 406a is Microsoft Windows (
R) may be designed to appear as a device driver for NT. Under this circumstance, the protocol server 406a causes the operating system 304 to
The I / O API presented in a will be the type of device interface understood by Windows (R) NT. Windows (R) NT is said to communicate with the protocol server 406a in the same way as it communicates with any storage device. The fact that the files stored in and retrieved from the protocol server 406a are actually stored in and retrieved from the database maintained by the database server 204 is due to the fact that Windows (R)
) Fully transparent to NT.

Some protocol servers used by translation engine 308 may expose device driver interfaces to their respective operating systems, while other protocol servers may appear as other types of entities. For example, operating system 304a is Micr
It may be the osoft Windows (R) NT operating system, where the protocol server 406a presents itself as a device driver, while the operating system 304b is the Microsoft Windows (R) 95 operating system and the protocol server 406b is It may also present itself as a system message block (SMB) server. In the latter case, protocol server 406b will typically be running on a machine separate from operating system 304b, and communication between operating system 304b and protocol server 406b will occur over a network connection. It will be.

In the above example, the source of the I / O command handled by the protocol server is the OS file system. However, translation engine 3
08 is not limited to use with the command of the OS file system. Rather, a protocol server may be provided to translate between DB file commands and some type of I / O protocol. Besides the I / O protocol used by the OS file system, other protocols with which a protocol server may be provided include, for example, the File Transfer Protocol (FTP).
: File Transfer Protocol, e-mail system (POP3 or IMAP)
The protocol used by 4) is mentioned.

An interface provided by a protocol server working with a non-OS file system will issue I / O commands, as well as an interface provided by a protocol server working with an OS file system being directed by a special OS. It will change based on the Deaf entity. For example,
A protocol server configured to receive I / O commands according to the FTP protocol will provide the FTP server's API. Similarly, protocol servers configured to receive I / O commands according to the HTTP, POP3 and IMAP4 protocols are respectively HTTP server, P
It will provide APIs for OP3 and IMAP4 servers.

Like the OS file system, each non-OS file protocol predicts the particular attributes held for that file. For example, most OS file systems store data indicating the last modified date of a file, while email systems indicate for each email message whether the email message was read or not. To store. The protocol server for each particular protocol implements the logic required to ensure that the semantics of that protocol are emulated in the database file system.

Transacted File System Within a database system, operations are generally performed as part of a transaction. Database systems perform all of the operations that are part of a transaction as a single atomic operation. That is, either all of the operations complete successfully, or none of the operations execute. During the execution of a transaction,
If an operation cannot be executed, then all previously executed operations of the transaction are canceled or "rolled back".

In contrast to database systems, OS file systems are not transaction based. Therefore, if a large file operation fails, the portion of the operation that was executed before the failure remains. Failure to undo incomplete file operations can lead to directory structure and file corruption.

According to one aspect of the present invention, a transaction processed file system is provided. As described above, translation engine 308 converts I / O commands into database statements sent to database server 204. The series of statements sent by translation engine 308 to perform the identified I / O operation is preceded by a begin transaction statement and ends with a close transaction statement. As a result, if any failure occurs during execution of those statements by database server 204, all changes made by database server 204 as part of that transaction will be rolled back to the time of the failure.

The circumstances that cause a transaction to fail can vary based on the system from which the I / O command originated. For example, the OS file system may support the concept of signatures, where a digital "signature" identifying the source of a file is attached to the file. A transaction initiated to store a signed file may fail, for example, if the stored file signature is not as expected.

On-the-Fly Intelligent File Conversion According to one embodiment of the present invention, files are processed before being inserted into a relational database and again when they are retrieved from that relational database. FIG. 9 is a block diagram showing the functional components of the DB file server 308 used to perform inbound and outbound file processing.

Referring to FIG. 9, the translation engine 308 includes a rendering unit 904 and a parsing unit 902. In general, the parsing unit 902 is responsible for inbound processing of files and the rendering unit 904 is responsible for outbound processing of files. Each of these functional units will now be described in more detail.

Inbound File Processing The inbound file is passed to the DB file server 408 via the DB file API. When you receive an inbound file, the parsing unit 9
02 identifies the file type of the file and then parses the file based on the file type. During the parsing process, parsing unit 902 extracts structured information from the file being parsed. This structured information may include, for example, information about the file being parsed, or data representing logically distinct components or fields of this file. This structured information is stored in the database along with the file from which the structured information originated. The database server may then be queried to select and retrieve files based on whether the structured information thus extracted meets certain search conditions.

The particular technique used by parsing unit 902 to perform parsing of a document, and the structured data it produces, may vary based on the type of document passed to parsing unit 902. become. Therefore, before performing any parsing operation, parsing unit 902 identifies the file type of this document. Various factors may be considered in determining the file type of a file. For example, DOS or Wind
In the ows (R) operating system, the file type of a file is often indicated by the extension in the file name of the file. That is,
If the file name ends in ".txt", the parser unit 902 classifies the file as a text file and gives the file a parsing technique specific to the text file. Similarly, if the file name ends in ".doc", the parser unit 902 classifies the file as a Microsoft Word document, and Micr
Gives the file a parsing technique specific to osoft Word. On the other hand, Maci
The ntosh operating system stores file type information for a file as an attribute held separately from the file.

Another factor that parsing unit 902 may consider to determine the file type of a file is, for example, the directory in which the file is located. Accordingly, parser unit 902 may be configured to classify and parse all files stored in the \ WordPerfect \ Documents directory as WordPerfect documents, regardless of their file names.

Alternatively, both the file type of the inbound file and the file type requested by the requesting entity are identified by or inferred from the information provided to the DB file server 408. There are also cases. For example, when a web browser sends a message, the message typically includes information about the browser (eg, browser type, version, etc.). When a web browser requests a file through the HTTP protocol server, this information is communicated to the DB file server 408. Based on this information, the rendering unit 904 can look up information about the capabilities of the browser and also infer the best file type from those capabilities and deliver it to the browser.

As mentioned above, the particular parsing technique used by parsing unit 902, and the type of structured data thus generated, will vary based on the type of file being parsed. For example, the structured data generated by parsing unit 902 may be embedded metadata, derivation (deri
ved) metadata and system metadata. Embedded metadata is information embedded in the file itself. Derived metadata is information that is not included in a file and can be derived by parsing the file. System metadata is data about a file provided by the system from which the file originated.

For example, assume that application 410 passes a Microsoft Word document to parsing unit 902. Parsing unit 902 parses the document to extract information about files embedded within the file. Microsof
Information embedded in a tWord document includes, for example, the author of the document, the category to which the document is assigned, and data indicating comments about the document.

In addition to locating and extracting embedded information for Word documents, parser 9
02 may also derive information about the document. For example, parser 902
A Word document may be scanned to determine the number of pages, paragraphs and words contained in this document. Finally, the system on which this document originated is
Data indicating the last modified date and file type may be provided to the parsing unit 902.

The more structured the file type of a document, the easier it is to extract a particular item of structured data from this document. For example, HTML documents typically have specific fields (title, heading 1, heading 2, etc.).
It has a delimiter or "tag" that identifies the beginning and end of the. These delimiters may be used by parsing unit 902 to parse an HTML document, resulting in an item of metadata for some or all of the delimited fields. Similarly, XML files are highly structured, and an XML parser could extract another item of metadata for some or all of the fields contained in the XML document.

Once the parsing unit 902 has created structured data for a file, the DB file server 408 issues a database command to the database server 204 to place the file in the file table (eg file table 710). Insert into a line. According to one embodiment, a database command issued in this manner stores this file as a BLOB in one column of that row and stores various items of structured data generated for that file in other columns of the same row. Store at.

Alternatively, some or all of the structured data items for a file may be stored outside the file table. Under these circumstances, a row that stores structured data associated with a file will typically include data that identifies the file. For example, a Word document is stored in row R20 of the file table, and the system metadata (
Assume that the creation date, modification date, etc.) is stored in row R34 of the system attribute table. In such a situation, both R20 of the file table and R34 of the system attribute table will typically include a FileID field that stores a unique identifier for the Word document. Then, the query retrieves both the file and the system metadata about the file by issuing a join statement that joins the row in the file table and the row in the system attribute table based on the FileID value. You can Techniques for storing file attributes in a table associated with a file "class" are described in more detail below.

Outbound File Processing Outbound files are rendered by the rendering unit 904 based on information retrieved in response to database commands sent to the database server 204.
Is built by. Once constructed, the outbound file is delivered to the entity requesting it through the DB file API.

Importantly, the file type (target file type) of the outbound file produced by the rendering unit 904 is not necessarily the same file type (source file) that produced the data used to build the outbound file. File type). For example, rendering unit 904 may build a text file based on the data originally stored as a Word file in the database.

Further, the entity requesting the outbound file may be on a completely different platform using a completely different protocol than the entity that originated the file from which the outbound file was constructed. For example, assume that the protocol server 406b implements the IMAP4 server interface and the protocol server 406a implements the HTTP server interface. Under these circumstances, email documents originating from the email application may be stored in the database through protocol server 406b and retrieved from the database by a web browser through protocol server 406a. In this scenario, parsing unit 902 calls the parsing technique associated with this email file type (eg, RFC 822), and the rendering unit calls a rendering routine that builds an HTML document from the email data retrieved from the database. Let's do it.

Registering Parsers and Renderers As mentioned above, the parsing technique applied to a file is dictated by the type of the file. Similarly, the rendering technique applied to a file is dictated by both the source type of the file and the target type of the file. The number of file types that exist across all computer platforms is huge. Therefore, it is not practical to build a parsing unit 902 that handles all known file types or a rendering unit 904 that handles all possible file type-to-file type conversions.

According to one embodiment of the present invention, the problem caused by the proliferation of file types is that the type-specific parsing module can be registered in the parsing unit 902, and the type-specific rendering module can also be rendered in the rendering unit 904. It will be dealt with by allowing registration in. A type-specific parsing module is a module that implements parsing technology for a particular file type. For example, Word documents are parsed using the Word document parsing module, while POP3 email documents are POP3.
It is parsed using the email parsing module.

Similar to the type-specific parsing module, the type-specific rendering module is a module that implements techniques for converting data associated with one or more source file types into one or more target file types. That is. For example, a type-specific rendering module can be provided to convert a Word document into a text document.

Conversion may be necessary even if the source file type and the target file type are the same. For example, when parsed and inserted into the database, the content of the XML document is not kept in a single BLOB but can span multiple columns in multiple tables. In that case, even if the data is XM
XML is the source file type for that data, even if it is not stored as an L file. The type-specific rendering module uses the data to generate XM
It can be provided to build an L document.

When parsing unit 902 receives an inbound file, parsing unit 902 determines the file type of the file and determines whether a type-specific parsing module is registered for that file type. If a type-specific parsing module is registered for the file type, parsing unit 902 calls the parsing routine provided by the type-specific parsing module. The parsing routines parse the inbound file to generate metadata, which is then stored with the file in the database. If a type-specific parsing module is not registered for that file type, parsing unit 902 will either generate an error or can apply general-purpose parsing techniques to the file. This general purpose parsing technique has no knowledge of the contents of the file, which limits the general purpose parsing technique as to the useful metadata that can be generated for the file.

When rendering unit 904 receives a file request, rendering unit 904 issues a database command to retrieve the data associated with that file. The data includes metadata that indicates the source file type of the file. Rendering unit 904 then determines whether a type-specific rendering module is registered for that source file type. If a type-specific rendering module is registered for that source file type, call the rendering routine provided by that type-specific rendering module to build the file and request the file thus constructed. Give to the entity that is doing.

Various factors may be used to determine which target file type should be selected by the type-specific rendering module. The entity requesting the file may also explicitly indicate the type of file it requires. For example, text editors can only work with text files. A text editor can request a file whose source file type is a Word document. In response to this request, a Word-specific rendering module is called which, based on the requested target file type, this Wo
Convert the rd document to a text file. This text file is then transported to the text editor.

In other cases, the entity requesting the file may support multiple file types. According to one embodiment, the type-specific rendering module identifies (1) a set of file types supported by both the requesting entity and the type-specific rendering module;
) Incorporate the logic of choosing the best target file type in the set. This selection of the best target file can take into account various factors, including the file-specific characteristics of the file in question.

For example, (1) the DB file server 408 receives a request for a file, and (2) the source file type of the file is “BM
(3) this request is initiated by an entity that supports "GIF", "TIF" and "JPG" images, and (3)
4) Rendering modules specific to BMP source type are "GIF", "JPG"
, And "PCX" target file types.
Under these circumstances, the BMP source type specific rendering module
Both GIF "and" JPG "are possible target file types. To select from these two possible target file types, the BMP source type specific rendering module may take into account information about the file, including its resolution and color depth. Based on this information, the BMP source type specific rendering module can determine that JPG is the best target file type, and this BMP file is
You can proceed to convert to a file. The resulting JPG file is then carried to the requesting entity.

According to one embodiment, type-specific parsing and rendering modules are registered by storing in a database table information indicating the capabilities of the module. For example, an entry for a type-specific rendering module might be that the source file type is XML and the requesting entity is Window.
It may indicate that it should be used if it is an s (R) based web browser.
The entry for the type-specific parsing module may indicate that the source file type should be used if it is a .GIF image.

When the DB file server 408 receives a command related to a file through the DB file API, the DB file server 408 determines the file type at the time of occurrence and the identity of the entity issuing the command. DB
The file server 408 then issues a database command to the database server 204, which causes the database server 204 to scan the table of registered modules and select the appropriate module for the current use. For inbound files, the appropriate parsing module is called to parse the file before inserting it into the database. For outbound files, the appropriate rendering module is called to build the outbound file from the data retrieved from the database.

According to an embodiment of the present invention, a DB file system allows object classes to be used to define a class of files, where each file type belongs to one file class and Classes can inherit attributes from other file classes. In such a system, the file class of a file can be a factor used to determine the appropriate parser and renderer for that file. The use of file classes will be discussed in more detail below.

Stored Query Directory As described above, a hierarchical directory structure can be implemented in a database system using a file table 710, where each row corresponds to a file. A hierarchical index 510 may be employed to efficiently locate the row associated with the identified file based on the file's pathname.

In the embodiment shown in FIGS. 5 and 7, child files of each directory are explicitly listed. In particular, the child files of each directory are listed in the Dir_entry_list of index entries associated with that directory. For example, the index entry 512 corresponds to the Windows (R) directory 614, and the Dir_entry_list of the index entry 512 is “Word” and “Access”.
Are explicitly listed as child files of the Windows® directory 614.

According to one aspect of the present invention, a file system in which child files of some or all directories are dynamically determined based on search results of a stored query rather than explicitly listed. Will be provided. Such directories are referred to herein as stored query directories.

For example, a file system user wants to group all files with the extension .doc into a single directory. In traditional file systems, the user creates a directory and searches for all files with the extension .doc and then either moves the files found in this search to the newly created directory or creates a new directory. Either make a hard link to the file found by the search, or. Unfortunately, the contents of this newly created directory only reflect the exact state of the system at the time the search was performed. Even if you change the name without the .doc extension, the fields will remain in the directory. Furthermore, files with a .doc extension created in other directories after the new directory was established are not included in this new directory.

Rather than defining membership of the new directory statistically, membership of this directory can be defined by stored queries. A stored query that selects files with the extension .doc can appear as follows.

Q1: SELECT ^* from files_table However, files_table.Extension = “doc” Referring to FIG. 7, when executed for the table 710, the query Q1 is Exam
Select lines R4 and R12, which are the lines for the two documents entitled "ple.doc".

According to one embodiment of the present invention, queries such as query Q1 are indexed into the hierarchical index 51.
A mechanism is provided for linking to the directory entry at 0. When traversing the hierarchical index 510, when a directory entry containing such a link is encountered, the query identified by this link is executed. Each file selected by this query is treated as a child of the directory associated with the directory entry, just as if the file was an explicit entry in the database table that stores the directory entry.

For example, suppose a user wants to create a directory “Documents” that is a child of Word 616, and that this document directory contains all files with the extension .doc. According to one embodiment of the invention, this user designs a query that specifies selection criteria for files that will belong to this directory. In this example, the user may generate the query Q1. This query is then stored in the database system.

As with other types of directories, a row for the Document directory is added to the file table 710 and an index entry for this Document directory is added to the hierarchical index 510. In addition, the index entry Dir_Entry_list for the Word directory is updated to indicate that the new Document directory is a child of the Word directory. Dir_Entry_li
Rather than explicitly listing the children in st, the new directory entry for this Document directory contains a link to the stored query.

10 and 11 respectively show the state of the hierarchical index 510 and the file table 710 after an appropriate entry is created for the Documents directory. Referring to FIG. 10, an index entry 1004 is created for the Documents directory. Since the children of the Documents directory are determined dynamically based on the result set of the stored query, index entry 100
The Dir_entry_list field of 4 is null. Instead of listing the child files statically, the index entry 1004 is stored query 100 that is to be executed to determine the child files in the Documents directory.
Includes a link to 2.

In addition to creating the index entry 1004 for the Documents directory, the existing index entry 514 for the Word directory is
Updated to indicate that s is a child of the Word directory. Specifically, the Dir_entry_list array entry is added to the index entry 514, and the RowID of the index entry for the name “Documents” and the Documents directory.
(Ie Y7) and the FileID of the Documents directory (ie X13)
Specify.

In the illustrated embodiment, the hierarchy index 510 has two additional columns.
Specifically, Stored Query Directory (SQD)
The column contains a flag that indicates whether the directory entry is for a stored query directory. In the directory entry for the stored query directory, a link to the stored query associated with the directory is stored in the Query Pointer (QP) column. In directory entries for directories other than stored query directories, the QP column is null.

The nature of the links may change for each implementation. For example, according to one implementation,
This link can be a pointer to the storage location where the stored query is stored. According to another implementation, this link may simply be a unique stored query identifier that may be used to look up the stored query in the stored query table. The present invention is not limited to any particular type of link.

Referring to FIG. 11, here, the line (R13) for the Documents directory is set.
A file table 710 updated to include According to one embodiment, the same metadata that is maintained for traditional directories is Documents.
It is also maintained for directories. For example, row R13 may include the creation date, last modified date, and so on.

FIG. 12 is a block diagram of a file hierarchical structure. The hierarchical structure shown in FIG. 12 is shown in FIG.
Same as the above, but a Documents directory 1202 is added. When any application requests to display the contents of the Documents directory 1202, the database executes the query associated with that Documents directory 1202. The query selects files that satisfy this query. The results of this query are then presented to the application as the contents of the Documents directory 1202. At the time shown in FIG. 12, the file system is
It contains only two files that satisfy the query associated with the Documents directory 1202. Both of these two files are titled Example.doc. Therefore, these two Example.doc files 618 and 622 are Documen
It is shown as a child of the ts directory 1202.

In many OS file systems, the same directory cannot store two different files with the same name. Therefore, the Documents directory 120
If two files named Example.doc exist in 2 then the rules of the OS file system may be broken. Various techniques may be used to address this issue. For example, the DB file system can add a character to each file name to create a unique file name. Therefore, Example.doc618
Can be presented as Example.doc1, whereas Example.doc622 is Example.do.
Presented as c2. The additional characters may be selected so as to convey the meaning rather than adding the characters that do not convey specific information. For example, the additional character may indicate the path to the directory where the file is statically located. That is, Example.doc 618 can be represented as Example.doc_Windows (R) _Word, while Example.doc 622 is represented as Example.doc_VMS_App4. Alternatively, the stored query directory may simply violate the rules of the OS file system.

In the example shown in FIG. 10, the child files in a given directory are either all defined statically or all defined by stored queries. However, according to one embodiment of the invention, a directory may have some statically defined child files and some child files defined by stored queries. For example, instead of having a null Dir_entry_list, index entry 1004 statically identifies one or more child files.
can have ry_list. Therefore, the application can
When asked to identify a child of the Documents directory, the database server will list a set of statically defined child files and child files that satisfy stored query 1002.

Importantly, a stored query that identifies child files in one directory may select other directories and documents. Some or all of such other directories may themselves be stored query directories. Under certain circumstances, a stored query for a particular directory may select itself and make it a child of itself.

The child files of the stored query directory are determined on the fly, so
The listing of child files will always reflect the current state of the database.
For example, assume that the "Documents" stored query directory was created as described above. Each time a new file with the extension .doc is created, it will automatically become a child of the Documents directory. Similarly, when a file's extension changes from .doc to .txt, that file automatically disqualifies itself as a child of the Documents directory.

According to one embodiment, the query associated with the stored query directory is
You can select a particular database record that is a child file of the directory. For example, the directory titled "Employees" is Emp in the database.
Can be linked to a stored query that selects all rows from the employees table. When an application requests a search for one of the virtual employee files, the renderer uses the data from the corresponding employee record to generate a file of the file type expected by the requesting application.

Stored Query Documents Just as stored queries can be used to identify child files of a directory, stored queries can also be used to identify the contents of a document. Referring to FIGS. 7 and 11, these figures show a file table 710 having a Body column. The Body field is null for directories. For documents, the Body field contains a BLOB that contains the document. For files whose content is specified by a stored query, the Body field may contain a link to the stored query. When an application requests a search of stored query documents,
The stored query linked to the row associated with the stored query document is executed. The content of the document is then constructed based on the result set of the query.
According to one embodiment, the process of constructing a document from the query results is performed by the renderer as described above.

In addition to providing support for documents whose content is completely determined by the results of a stored query, support is also provided for documents that are determined in part by the query results but not in others. May be brought. For example, the Body column of a row in the document directory may contain a BLOB, with another column containing a link to the stored query. The query may be executed upon receiving a request for the file associated with that row, and the result of the query may be combined with the BLOB in rendering the file.

Multi-Level Stored Query Directory As mentioned above, stored queries may be used to dynamically select a child file of a directory. All child files of a directory belong to the same level in the file hierarchy (ie, the level directly below the directory associated with the stored query). According to an embodiment, a stored query associated with a directory may define multiple levels below the directory. The directories associated with queries that define multiple levels are referred to herein as multi-level stored query directories.

For example, a multi-level stored query directory may be associated with a query that selects all employee records in the employee table and groups these employee records by department and region. Under these conditions,
There may be a separate hierarchy level for each grouping key (department and region) and employee record. Specifically, the results of such queries may be represented as three different levels in the file hierarchy. The child files of the directory are defined by the first grouping criterion. In this example, the first grouping criterion is "department". Therefore, the child files of the directory are different department values, namely "Dept1", "Dept2" and "Dept3".
May be These child files are themselves represented as directories.

The child files of the department directory will be defined by the second grouping standard. In this example, the second grouping criterion is "region". Therefore, each department directory has "North", "South", "East", "
You will have a child file for each regional value such as "West". Regional files are also represented as directories. Finally, the child files of each region directory will be the files corresponding to a particular department / region combination associated with the region directory. For example, a child of the \ Dept1 \ East directory would be an employee in Department1 in the East area.

Handling File Operations for Stored Query Directory Child Files As described above, stored query directory child files are presented to the application in a manner similar to conventional directory child files. However, certain file operations that may be performed on child files of conventional directories pose special problems when performed on child files of stored query directories.

For example, assume that the user has entered that specifies that the child files of the stored query directory should be moved to another directory. This operation is problematic because it belongs to the stored query directory due to the fact that the child files meet the criteria specified in the stored query associated with the directory. Unless you modify the file in such a way that it no longer meets that criterion, it will continue to qualify as a child file of the stored query directory.

A similar problem occurs when an attempt is made to move a file to the stored query directory. The file does not satisfy the stored query associated with the stored query directory if the file is not already a child of the stored query directory. A file should not be a child of a stored query directory unless it is modified in such a way that it meets the criteria specified by the stored query.

Various approaches can be taken to solve these problems. For example, the DB file system may be configured to issue an error in response to an operation attempting to move a file into or out of the stored query directory. Alternatively, the DB file system may respond to such attempts by deleting the file in question (or the database record represented as a file).

In yet another approach, files moved into the stored query directory may be automatically modified so that they meet the stored query criteria associated with the directory. For example, assume that the stored query associated with the stored query directory selects all married employees. When the file corresponding to an employee record is moved to the stored query directory, the "married" field in the employee record is updated to indicate that the employee is married.

Similarly, files moved out of the stored query directory may be automatically modified so that they no longer meet the stored query criteria associated with the directory. For example, if a file in the "Married Employees" stored query directory is moved out of that directory, the "Married" field in the corresponding employee record is updated to indicate that the employee is not married. To do.

If an attempt is made to move a file that does not meet the stored query criteria into the corresponding stored query directory, another approach is to update the stored query directory index entry and store the file in the stored query directory. Statistically established as a child of. Under these circumstances, the stored query directory will have some child files that are child files because they satisfy the stored query, and other child files that have become child files because they were manually moved to the stored query directory. Will have.

Programmatically Defined Files Stored query directories and stored query documents are examples of programmatically defined files. A programmatically defined file is an entity (eg, a document or directory) represented as a file to the file system, but whose contents and / or child files are defined by executing code. is there. The code executed to define the contents of the file may include a stored database query, as in the case of a stored query file, and / or may include other code. According to one embodiment, the code associated with the programmatically defined file implements the following routines.

Resolve_filename (filename): child_file_handle; list_directory; fetch; put; delete; Bring back. The list_directory routine returns a list of all child files of a programmatically defined file. The fetch routine retrieves the contents of a programmatically specified file. The put routine inserts data into a programmatically specified file. The delete routine deletes a programmatically specified file.

According to one embodiment, a "resolve_pathname (path): file_handle" routine is also provided. The resolve_pathname routine receives a path and iteratively calls the resolve_filename function for each filename in the path.

According to one embodiment, the DB file system provides an object class that implements the routines listed above for conventional files (ie, files that are not programmatically defined). For purposes of explanation, that object class will be referred to herein as a "directory class". Subclasses of the directory class are established to implement programmatically defined files. The subclass inherits the routines of the directory class, but allows the programmer to override the implementation of these routines. The implementation provided by the subclass determines the operations performed by the DB file system in response to file operations involving programmatically defined files.

Event Notification in File System According to one aspect of the present invention, there is provided a file system in which a user is proactively notified when a certain file system event occurs. These are proactively notified, thus avoiding the overhead of repeated polling to detect conditions that indicate an event of interest has occurred.
The ability to be notified when a file system event occurs, for example,
It is very useful, for example, when a particular file system event has a significant meaning to the user.

For example, it is common for multiple copies of a document to be maintained (“cached”) at different locations, resulting in more efficient access to the document. Under these conditions, if one of the copies is updated, the remaining copies become obsolete (ie, these copies no longer reflect the current state of the document). By using the event notification method described below, when one copy is updated, a site where another copy exists can be proactively notified of the update. The process or user at these sites can then take whatever action is appropriate under the circumstances. In the case of caching, the appropriate action may be, for example, replacing the cached version of the document with an updated version.

As another example, a particular user may be responsible for reviewing all of a company's technical documents before they are published. The technical writer for that company
It may be instructed to store all technical documents in the "Ready to Review" directory when they are ready for review by the user.
Without a proactive notification system, simply storing technical documents in a "ready for review" directory does not remind the user that a new document is ready for review. Rather, some additional work is required such as the technical writer notifying the user that the document is ready for review, or the user periodically checking the "Review Ready" directory. On the other hand, in the file system that realizes the event notification method described here, the user is notified that the new technical document is ready to be reviewed by putting the technical document in the “ready for review” directory. The generation of a message for the user to notify can be triggered.

According to one embodiment of the present invention, rules may be defined for proactively generating messages for file system events. Such events include, for example, storing or creating a file in a particular directory,
This includes deleting files in certain directories, moving files from certain directories, modifying or deleting certain files and linking files to certain directories. These file system operations are merely representative. The specific operations for which proactive notification rules may be created may vary from implementation to implementation. The present invention is not limited to providing event notification support for any particular set of file system operations.

According to one embodiment, event_id is assigned to a file system event.
Therefore, a notification rule may be created that identifies an event_id and a set of one or more subscribers. Once a rule is registered in the file system, the rule ev
In response to the occurrence of the file system event identified by ent_id, a message is automatically sent to the set of consumers identified in the rule.

For example, a user may register interest in knowing when a file is added to a particular directory. To record this interest,
The database server inserts a row into the (1) "registration rule" table,
) Set a flag associated with the directory to indicate that at least one rule has been registered for that directory. Rows inserted into the table of registered rules identify the entity and indicate the event that the entity is interested in. The row may also include additional information such as the protocol to use to communicate with that entity. A flag indicating that a rule applies to a directory may be stored in a row of a table of files associated with the directory, in a hierarchical index entry associated with the directory, or both.

When inserting a file into a directory, the database server examines the flags associated with the directory to determine if any rules are registered for that directory. If a rule is registered for that directory, search the table of registered rules to find the specific rule that applies to that directory. If the registered rules contain rules that apply to the particular operation being performed on the directory, then a message is sent to the interested entity identified by these rules. The protocol used to send a message to an entity may vary from entity to entity. For example, for an entity, the message is CO
It may be sent via RBA, while for other entities the message may be sent in the form of HTML pages via HTTP.

According to one embodiment, the notification mechanism is a message queue in a database system submitted by Chandra et al. On October 31, 1997, all of which is incorporated herein by reference. Apparatus and methods for
A database implementation, as described above, using a queuing mechanism such as that described in US patent application Ser. No. 08 / 961,597 entitled "APPARATUS AND METHOD FOR MESSAGE QUEUING IN A DATABASE SYSTEM". Implemented with a type file system.

According to one such embodiment, an event server running external to the database server is registered as a subscriber to a queue managed by the database server. The queue to which the event server subscribes will be referred to herein as the file event queue. Entities interested in a particular file system event register their interest with the event server. The event server communicates with the database server via the database API and with interested entities via the protocols they support.

When the database server performs a file system related operation, it places a message in the database server file event queue indicating the event_id associated with the operation. The queuing mechanism determines that the event server has registered interest in the file event queue and sends a message to the event server. The event server searches the list of interested entities to determine if any of the entities have registered interest in the event identified in the message. The event server then sends a message indicating the occurrence of a file system event to all entities that have registered interest in the event.

In embodiments in which an event server is used to transfer messages to interested entities, the event server may be configured to support a certain maximum number of users. If the number of interested users exceeds the maximum, an additional event server is started to serve the additional users. As with the single event server case, each event server in a multiple event server system is registered as a subscriber to the file event queue.

According to an alternative embodiment, entities interested in file system events are directly registered as subscribers to the file event queue. As part of the registration information, the entities indicate the event_id of the file system event they are interested in. When the queue mechanism puts a message in the file event queue, the queue mechanism does not automatically send the message to all queue subscribers. Rather, the queuing mechanism examines the registration information to determine which entities are registering interest in the particular event associated with the message and selectively sends the message only to those entities. For entities that do not support database APIs, the registration information will include information about the protocols supported by these entities. The queuing mechanism sends to these entities file event messages using the protocols listed in their registration information.

File system event notifications can be applied in various contexts. For example, it may sometimes be desirable to store a cache of files residing on a second machine on a first machine. One of the currently available mechanisms for implementing such a file cache is the "briefcase" feature provided by the Microsoft Windows (R) operating system. The briefcase feature allows a user to create a special folder ("briefcase") on one machine and copy files stored on other machines into that briefcase. Each briefcase has an "update" option, which, when selected, causes the file system to compare the copy of the file in the briefcase with the copy of the file in its original location. If the files do not have the same modification date, the file system allows the user to synchronize the two copies (typically by overwriting the older copy with the newer copy).

Unlike the briefcase mechanism, the file system event notification mechanism allows the file cache to be proactively updated so that the file cache always reflects the current state of the file in its original location. To do so. For example, a process that manages a file cache may register interest in updates to the original copy of the files contained in the cache. This allows the process to be automatically notified when any of the original files have been updated and can immediately copy the updated files into the file cache in response. . Similarly, a file system event notification mechanism may be used to mirror one or more directories residing on a second machine on a first machine. To use the file system event notification mechanism in this manner, the process for maintaining a mirrored directory first makes a copy of the directory and all the files it contains, then the directory. And register its interest in the changes made to the files contained in the directory. When notified that a change has been made to the directory, the process makes the corresponding change to the copy of the directory.
Similarly, when notified of a change to any of the files in the mirrored directory, the process makes a corresponding change to the copy of the file.

For example, if a file is moved from a mirrored directory to a non-mirrored directory, the process removes the copy of the file from the mirrored directory and unregisters interest in that file. . Therefore, the process does not continue to be notified when the file is updated. Similarly, if a file is moved from a non-mirrored directory to a mirrored directory, the process will be notified that the directory has changed. In response to the message, the process identifies the new file, makes a copy of the new file in the mirrored directory, and registers its interest in the new file.

Version Management in File System In the workplace, a large-scale work in which a large number of people work together for a long period of time is called a “project”. When working on a project, employees typically create a number of documents, each of which is in some way related to the project.

Similarly, within a computer system, users often create a large number of electronic documents, all related to a project. For example, programmers located at numerous sites around the world may each be working on different parts of the same computer program. The electronic documents they generate for that computer program typically contain source code files, but belong to a single project. That is, in the context of this discussion, a project is a collection of related files.

Typically, project files will be organized into specific folders. For example, FIG. 13 shows an example of how the files associated with the project “Big Project” are organized into various folders. Figure 1
3, a folder 1302 entitled Big Project was created to hold all files (directories and documents) associated with that project. The child file just under Big Project 1302 is the folder sourc
e code 1304 and folder docs 1306. source code 1304 is
Source code 1316 and source code 1 for programmers located in Los Angeles
It contains two directories, a LA code 1312 for storing 318 and a SF code 1314 for storing source code 1320 of a programmer located in San Francisco. docs 1306 contains two folders, specs 1308 and user manual 1310. specs 1308 includes specs 1322 and specs 1324. The user manual 1310 includes UM1326.

Often, a file in one project will contain a reference (eg, an HTML link) to another file in the same project. These references typically identify other documents using the full pathname of the document. Therefore, if a document is moved from one location to another in the directory hierarchy, or if the document is renamed, all references to that document will be invalid.

Due to the presence of inter-document references, new versions of files are typically stored in the same location with the same name as the older versions they replace. In traditional file systems, this process overwrites older versions of the file, making it impossible to recover. Unfortunately, there are often times when it is desirable to recover an older version of a file. For example, newer versions may inadvertently delete important information. If it is impossible to recover an older version, the user will have to spend considerable resources recreating the lost material, if it can. unknown. In addition, it is often possible to restore the history of changes to a file, determine when a particular change was made, or change something at some point. It is desirable to be able to determine what has been done.

According to one aspect of the invention, a versioning mechanism in which a new version of a file is saved in the same location in the directory hierarchy with the same name as the older version without overwriting the older version. Will be provided. Instead of overwriting the older version, the older version is retained and the user can selectively retrieve the older version of the file. In addition, older versions are kept in their original place in the directory hierarchy. As described in more detail below, a new directory versioning technique is provided that allows a file system to keep multiple versions of the same file with the same name at the same location in the directory hierarchy.

Any reference to the first version of a file should continue to point to the first version of the file even if a newer version of the file is created, since the creation or creation of a new version does not change the name or location of the original version. Becomes Thus, an inter-file reference contained within a document refers to the correct version of the referenced document, even if a newer version of the referenced document is created. The fact that cross-file references remain valid in the versioning process (ie, continue to refer to the correct version of the referenced file) has a significant beneficial impact on the efficiency of file retrieval. Specifically, the referenced file does not need to perform a lookup operation to find the appropriate version of the referenced file, but the referenced file follows references to those contained within other files. Can be searched directly by.

Similarly, the lookup operation need not be involved in the process of determining the contents of the directory at any particular time. Since directories are themselves versioned, selecting a particular version of a directory simply selects the members of the directory. The selected version of the directory will contain a direct link to the correct file belonging to that version of the directory, and thus to the correct version of the file.

A method is also provided for tracking the relationship between versions of the same file even when the file name changes for each version. In addition to the file's name, a FileID and version number are maintained for each version of each file, as described in more detail below. If two files have the same FileID, they are different versions of the same file, even if they have different names.

According to one aspect of the present invention, a “view” of the project that the user wants to see.
A mechanism is provided that allows the user to select the (view). The view of a project represents the files of the project as they existed at a particular point in time. For example, the default view presented to the user may represent the latest version of all files. Another view may represent the version of the file that was the most recent one day ago. Another view may show the version of the file that was most recent a week ago.

According to one embodiment, a version tracking mechanism is provided by storing a version number with each file in a project. For example, in a file system implemented in a database system that uses a file table, such as file table 710, one column of a row associated with a file may store the version number for that file. Each time a file is created, a row for the file is inserted into the file table 710 and the first predetermined version number (eg, 1) is stored in the version column for that row.

When a file is updated, the previous version of the file is not overwritten. Instead, a new row is inserted in the file table for the new version of the file. The row for the new version has the same FileID, Name and Cr as the original row
eation Date included, but higher version number (eg 2), new M
It includes the odification Date and possibly different file sizes.
Furthermore, the BLOB that stores the contents of the file will reflect the update, but the BLOB of the original entry will not change.

According to one embodiment, if a file and the directory in which the file resides both belong to a project, changes to the file effectively create a new version of the directory. Thus, updating a file in a directory not only creates a file table row for the new version of the file, but also a file table row for the new version of the directory. In one embodiment using a hierarchical index, the index entry for the new version of the directory will also be added to the hierarchical index.

If a directory and a parent directory both belong to the same project, creating a new version of the directory effectively creates a new version of the parent directory. This also adds a new row to the file table and hierarchy index for the directory's parent directory. This process continues, and a new version is created for every directory that belongs to a project and exists above the updated files in the file hierarchy.

To show how the versioning mechanism responds to updates of files belonging to a project, assume that all files shown in FIG. 13 are version 1 and that updates have been made to code 1320. I assume. As shown in FIG. 14, the versioning mechanism responds to the update by creating a new version of code 1320 'without deleting the original version of code 1320. The code 1320 belongs to the SF code directory 1314, so that a new version of the SF code directory 1314 'is created without deleting the original version. SF code directory 1314 is source code directory 1304
A new version of the source code directory 1304 'is created without deleting the original version. Finally, source code directory 1
304 belongs to big project directory 1302, so new version b
ig project 1302 'is created without deleting the original version.

As shown in FIG. 14, when a new version of a parent file is created in response to a new version of a child file, the new version of the parent file is updated rather than the original version of the updated file. It still has the same children as it had before the update, except that the new version of the file is a child. For example, the new version of code 1320 'is the new version of SF code13.
14 'child. The new version of SF code 1314 'is a child of the new version of source code 1304'. However, the original source code 130
4 unchanged child files (eg, LA code 1312) continue to be newer versions of the source code 1304 'child files. Similarly, the new version of source code 1304 'is a child of the new version of big project 1302', but the original big project's unchanged child files (eg docs 1306).
) Remains a new version of the big project 1302 child files.

In an embodiment where the file system is implemented using a hierarchical index, the index entry created for the new version of the directory is such that the array entry for the updated child file is the array entry for the new version of the child file. It will contain the same Dir_entry_list as the index entry for the previous version of the directory, except that it will be replaced. If the updated child file was a child directory, Di for the new directory
The r_entry_list array entry will contain the RowID in the hierarchical index of the index entry for the new version of the child directory.

When a file belonging to a project is moved from one directory in that project to another directory in that project, a new version of the file is not created because the file itself has not changed. However, both the original directory where the file was moved and the directory where the file was placed have changed. Therefore, new versions are created for these directories and all ancestor directories of these directories in the same project. FIG. 15 shows a new directory that will be created in response to code 1318 of FIG. 13 moved from LA code 1312 to SF code 1314. Specifically, the new version of LA code1
312 'and SF code 1314' will be created. The new version of LA code 1312 'does not have code 1318 as its child. Rather, code1
318 is a child of the new version of SF code 1314 '. New source code
A directory 1304 'is created and linked to the new version of LA code 1312' and SF code 1314 '. New big project directory 130
2'created with new source code 1304 'and original docs directory 1
Linked to 306.

Using the versioning technique described above, one project (eg big projec
Each time a change is made to t1302) a new version of the project root directory is created. A link that is derived from each version of the root project directory links all the files that belonged to that project to each other at a particular point in time, and the versions of the files linked in this way existed at that particular point in time. It is a version. For example, referring to FIG. 14, the link derived from big project 1302 is code13.
It reflects the project as it existed before the update to 20. bi
The links derived from g project 1302 'reflect the project as it existed immediately after the update to code 1320. Similarly, in FIG.
The link derived from g project 1302 is code 1318 from LA code 1312
It reflects the project as it existed before moving to SF code 1314.
For links derived from big project 1302 ', code 1318 is LA code 1312
Reflects the project as it existed immediately after moving from to SF code 1314.

Tagging Unfortunately, the versioning approach described above results in a significant surge of file versions, especially in directories at higher levels of the project. In some circumstances, such a surge may not be necessary or desirable. Thus, according to one embodiment of the present invention, a mechanism is provided for "tagging" a version of a file. Tagging the version of a file indicates that that version of the file should be retained. That is, rather than always retaining the older version of the file when the newer version is created, the older version of the file is retained only if it is tagged. Otherwise, they will be replaced (overwritten) when a newer version is created.

Referring to FIG. 13, assume that code 1320 is untagged. co
When de1320 is updated, the new version of code is simply replaced by the old version of code. Only if code 1320 is tagged, as shown in FIG. 14, code 1320, SF code 1314, source code 1304 and bi
A separate new version of g project 1302 will be created.

In many cases, tags will be applied to all files within a project at the same time. For example, if a particular version of a software program is released, then all source code used to create the released version of the program may be tagged at that time. This makes the exact same set of source code associated with the released version available for later reference, regardless of subsequent revisions to the source code files.

In embodiments where tags are always applied to the project as a whole, a single tag may be maintained for the root project directory. If you use the tagged version of the root project directory to locate a file, any changes to that file will create a new version of that file, while the original version of that file will Retained. Conversely, if the location of a file is verified using the untagged version of the root project directory, any changes to that file will simply overwrite the previous version of the file.

According to another embodiment, applying a tag to a file effectively applies the tag to all files below that file in the file hierarchy. For example, assume that the tag applies to LA code 1312. code1318 is L
When moved out of A code 1312, a new version of LA code 1312 is created. If code1318 is updated, code1318 and LA code1
Both new versions of 312 are created. In such an embodiment, if the location of a file is verified by traversing the file hierarchy through all tagged files, any changes to that file will create a new version of the file. If the location of a file is verified without traversing any tagged files in the hierarchy, then any changes to that file will overwrite the previous version of that file.

Purge Count Another approach to reduce version spikes that can be used instead of or in addition to tagging involves maintaining a purge count. The purge count indicates the maximum number of versions that will be kept for any given file. When a new version is created for a file that has already reached the purge count of versions, the new version of the file overwrites the oldest retained version of the file. The purge count may be implemented on a file-by-file system, project-by-project basis, or file-by-file basis. When implemented on a file-by-file system basis, a single purge count applies to all files maintained in the file system. On a project-by-project basis, all files in a given project may have the same purge count, but different projects may have different purge counts. On a file-by-file basis, different purge counts may be specified for each file.

When used in combination with tagging, the purge counting mechanism can be implemented in various ways. According to one embodiment, tagged files are ignored for the purpose of determining if creating a new version of a file will exceed the purge count, and tagged files are purged by the purge count mechanism. Is never deleted. For example, assume that the purge count for a file is 5, that is, there are 5 versions of the file, and that one of these 5 versions is tagged. When an update is made to that file, the purge count mechanism determines that there are currently only four untagged versions of that file, and thus
Create another version of the file without deleting any of the existing versions. If the same file is updated again, the purge count mechanism determines that there are five existing untagged versions of the file, and thus in response to creating a new version, the oldest untagged version of the file. To delete.

Inter-Project Links Each link has a source file (the original file that the link is extended from) and a target file (the file that the link points to). In the file hierarchy, the source files for links are often directories and the target files for links are files within directories. However, not all links are between a directory and its children. For example H
TML files may include hyperlinks to graphic images and other HTML files. In the file system realized by using the hierarchical index, these hyperlinks can be handled in the same manner as the directory-document link.

A view of the file system shows how each project in the file system existed at a particular point in time. However, the time associated with one project in one view may be different than the time associated with another project in the same view.
This causes problems if the source file of the link belongs to a different project than the target file of the link. For example, assume that a view identifies a time T1 for a project P1 containing a file F1 and a later time T2 for a project P2 containing a file F2. Further assume that file F2 has a link to file F1. The links contained in the T2 version of F2 go to the T2 version of P1, not to the T1 version of P1. However, that view identifies the T1 for P1, so any T1 version of P1 used for any file in P1 via that view should be used.

According to one embodiment of the invention, an "inter-project boundary" flag is maintained for each link. The inter-project boundary flag for a link indicates whether the source and target files for that link are in the same project. In a file system that uses a hierarchical index such as the hierarchical index 510, the inter-project boundary flag is, for example, Dir_entry of the index entry.
It may be stored in each array entry of _list.

In a file hierarchy traversal, the inter-project boundary flag of every link is checked before following that link. If the inter-project boundary flag for a link is set, the required version time of the project to which the source file belongs is compared to the required version time of the project to which the target file belongs. If the desired version times are the same, the link is traversed. If the desired version times are not the same, a search is performed for the version of the target file that corresponds to the required version time of the project to which the target file belongs.

For example, the inter-project boundary flag of the link between F2 and F1 will be set. This compares the required version time of P2 with the required version time of P1. The required version time of P2 is T2, which is not the same as the required version time of P1. Therefore, P1 would not be able to ascertain its location by following the link. Instead, a search will be performed to locate the version of P1 corresponding to time T1.

According to an alternative embodiment, no inter-project boundary flags are maintained. Instead, each time a link is encountered, the required version time of the source file is compared to the required version time of the target file. If the source and target files are in the same project or in different projects with the same required version time, follow that link.
Otherwise, the search is done for the correct version of the target file.

Object-Oriented File System In recent years, object-oriented programming has become a standard programming standard. In object-oriented programming, the world is modeled in terms of objects. An object is a record that is associated with the procedures and functions that manipulate the record. All objects in an object class have the same fields (“attributes”) and are manipulated by the same procedures and functions (“methods”).
An object is said to be an "instance" of the object class to which it belongs.

At times, applications may require the use of similar but not identical object classes. For example, the object classes used to model both dolphins and dogs may include nose, mouth, length and age attributes. However, the dog object class may require a coat color attribute, while the dolphin object class may require a fin size attribute.

Object-oriented programming supports “inheritance” to facilitate programming in situations where an application requires multiple similar attributes. Without inheritance, the programmer would have to write one set of code for the dog object class and a second set of code for the dolphin object class. Code that implements the attributes and methods common to both object classes will be duplicated in both object classes. Duplicating code in this manner is very inefficient, especially when the number of common attributes and methods is much greater than the number of unique attributes. In addition, code duplication between object classes complicates the code revision process. This is because changes made to common attributes must be replicated at multiple places in the code to maintain consistency across all object classes that have that attribute.

By inheritance, it is possible to establish a hierarchical structure between object classes.
The attributes and methods of a given object class automatically become the attributes and methods of the object class based on the given object class in the hierarchy.
For example, the "animal" object class may be defined as having nose, mouth, length and age attributes, along with associated methods. By adding these attributes and methods to the dolphin and dog object classes, programmers can specify that the dolphin and dog object classes "inherit" the animal object class. Under these circumstances, the dolphin and dog object classes are said to be "subclasses" of the animal object class, but the animal object class is said to be the "parent" class of the dog and dolphin object classes.

According to one aspect of the present invention, a mechanism for applying an object-oriented standard including inheritance to a file system is provided. Specifically, each file in the file system belongs to a certain class. File system classes define, among other things, the type of information the file system stores about its files. According to one embodiment, a base class is provided. A file system user may register other classes there, which may be defined as a base class or a subclass of any previously registered class.

When a new file class is registered with a file system, the file system is effectively extended to support new types of files and interactions with the new type of file system. For example, most email applications expect email documents to have a "priority" property. If the file system does not provide a memory for priority properties,
Email applications may not work correctly with email documents stored in that file system. Similarly, some operating systems may expect some type of system information to be stored with the file. If the file system does not store that information, the operating system may encounter problems. A particular type of system or protocol (eg, a particular operating system, FTP, HTTPP,
Registering a class that contains all the attributes needed to support IMAP4, etc.) allows for accurate and transparent interaction with that system or protocol.

To register a class, information about that class is provided, which identifies the parent class of the class and has any attributes that the class does not have. Contains the data to describe. The information may also identify a particular way to operate on an instance of that class.

The file system itself is an object-oriented file system that enables users to register file classes, supports inheritance between file classes, and stores information about files based on the class to which the files belong. It can be implemented in various ways depending on the context in which it is performed. According to one embodiment, the object oriented file system is provided in the context of a database-implemented file system as described above. Various aspects of an object-oriented file system are described in connection with database-implemented embodiments,
The object oriented file system approach described here is not limited to such an embodiment.

Database Implementation of Object-Oriented File System According to one embodiment, a database-implemented file system has a base class, and subclasses of the base class can be registered in the file system. Referring to FIG. 16, an exemplary set of file classes is shown.
The base class is titled "Files" and contains attributes that are commonly common to all files including name, creation date and modification date. Similarly, the Files class method
Includes methods for operations that can be performed on all files.

According to one embodiment, the attributes of the Files class are a union of all the attributes maintained by the operating system with which the database-implemented file system will be used. For example, assume that a file system is implemented in a database maintained by server 204 as shown in FIG. The files stored in that file system originated from operating system 304a and operating system 304b,
These operating systems do not necessarily support the same set of file attributes. Thus, the set of attributes of the Files class of the file system implemented by the database server 204 is a union of the set of attributes supported by the two operating systems 304a and 304b.

According to an alternative embodiment, the attributes of the Files class are intersections of all the attributes maintained by the operating system with which the database-implemented file system is used. In such an embodiment, a subclass of the Files class could be registered for each operating system. A subclass registered for a given operating system can extend the base Files class by adding all of the attributes supported by the given operating system that are not already included in the base Files class. Become.

In the example illustrated in FIG. 16, two subclasses of Files of the “Document” class and the “Folder” class are registered. The Document class inherits all of the attributes and methods of the Files class, and adds document file-specific attributes. In the illustrated example, the Document class adds the attribute "size".

The Folder class inherits all of the attributes and methods of the Files class and adds attributes and methods that are specific to folder files (ie files, such as directories, which can contain other files). . In the illustrated embodiment,
The Folder class introduces a new attribute "max_children" and a new method "dir_list". The max_children attribute may indicate, for example, the maximum number of child files that can be included in a given folder. The dir_list method may, for example, provide a list of all child files in a given folder.

In the class hierarchy structure illustrated in FIG. 16, the Document class includes e-mail and Te.
It has two registered subclasses of xt. Both of these subclasses are Docu
Inherits all the attributes and methods of the ment class. In addition, the e-mail class is Re
It contains three additional properties: ad_flag, priority and sender. The Text class has one additional attribute, CR_Flag, and an additional method Type. CR_Flag may be a flag that indicates whether the text document includes a "carriage return" symbol. The Type method outputs a text document to an input / output device such as a computer monitor.

File Class and File Format The internal structure of a file is called the “format” of the file. Typically, the file format is determined by the application that creates the file. For example, a document created by one word processor may have the same semantic content as another document created by another word processor, but have a completely different format. Some file systems maintain a mapping between document format and filename extension. For example, all files with filenames ending in .doc are presumed to be files created by a particular word processor, and thus presumed to have internal structure imposed by that word processor. In other file systems, information about the format of a document is maintained in a separate metafile associated with that document.

In contrast to the file format, the file class mechanism described here does not relate to the internal structure of a document. Rather, the file class of a file determines what information the file system maintains for that file, and what operations the file system can perform on the file. For example, documents created by multiple word processors can all be instances of the Document class. Therefore, the file system maintains the same attribute information about the document and enables the same operation on the document even if the internal structure of the document is completely different.

Class Tables According to one embodiment, an object oriented file system is implemented in a relational database system in which a relation table is created for each class of file. FIG. 17 is an example of a table that can be created for the classes illustrated in FIG. Specifically, Files table 1702, document table 1704, E
-mail table 1706, text table 1708 and folder table 1708
Are the Files class, Document class, E-mail class, Text class and F, respectively.
Corresponds to older classes.

According to one embodiment, the class table for a given class includes (1) files belonging to that given class and (2) any descendants of that given class.
cendant) Contains lines for files that belong to the class. For example, in the illustrated system, the Files class is a base class. Therefore, every file in the file system is a member of the Files class or its descendants. Therefore, the Files table will contain a row for every file in the file system. On the other hand, E-mail class and Text class are Docume
It is a descendant of the nt class, but not the Files and Folder classes. Thus, the Document table 1704 contains rows for all files of class Document, E-mail or Text, but not for files that are of class Files or Folder.

The table for each class includes a column that stores the values for the attributes introduced by that class. For example, the Document class inherits the attributes of the Files class,
Add size attributes to these attributes. Therefore, the Document table includes a field for storing the size value for the size attribute. Similarly, the E-mail class inherits the attributes of the Document class and introduces read_flag, priority and sender attributes. Therefore, the E-mail table 1706 includes columns for storing the read_flag value, the priority value, and the sender value.

Five files are stored in the file system shown in FIG. The file named File1 is stored in RowID X1 in the Files table 1702. The FileID of File1 is F1. The class of File1 is the File class, as indicated by the value stored in the Class column of row X1. File1 is Fi
Being an instance of the les class, the Files table 1704 is the only class table containing information for File1. Therefore, the only attribute value stored for File1 is the value for the attribute associated with the Files class.

The file named File2 is stored in RowID X2 in the Files table 1702. The FileID of File2 is F2. The File2 class is the Document class, as indicated by the value stored in the Class column of row X2. File2
Is an instance of Document class, so Files table 1702 and Doc
The ument table 1704 includes information on File2. That is, the attribute values stored for File2 are the values for the attributes associated with the Document class, including the attributes inherited from the Files class.

The file named File3 is stored in RowID X3 in the Files table 1702. The FileID of File3 is F3. File3 class is E-mail class,
This is as indicated by the value stored in the Class column of row X3. File3
Since it is an instance of the E-mail class, the Files table 1702, Document table 1704, and E-mail table 1706 all include information for File3. That is, the attribute values stored for File3 are Document class and Files
Values for attributes associated with the E-mail class, including attributes inherited from the class.

The file named File4 is stored in RowID X4 in the Files table 1702. The FileID of File4 is F4. The class of File4 is the Text class, as indicated by the value stored in the Class column on line X4. File4 is Te
Since it is an instance of xt class, Files table 1702, Document 170
4 and Text table 1708 contains information for File4. That is, the attribute values stored for File4 are the values for the attributes associated with the Text class, including the attributes inherited from the Document and Files classes.

The file named File5 is stored in RowID X5 in the Files table 1702. The FileID of File5 is F5. File5 class is Folder class,
This is as indicated by the value stored in the Class column of row X5. File5
Since it is an instance of Folder class, Files table 1702 and Folder
Table 1708 contains information for File5. That is, the attribute values stored for File5 are the values for the attributes associated with the Folder class, including the attributes inherited from the Files class.

According to one embodiment of the invention, the files in the class table are accessed by traversing the hierarchical index as described above in connection with FIGS. 5 and 8. The traversal of the hierarchical index (as done in pathname derivation) produces the RowID of the row in the Files table 1702 corresponding to the target file. From that line, the attribute value for the Files class attribute is retrieved. However, for files belonging to other classes, additional attributes may have to be retrieved from other class tables. For example, File3
In contrast, the creation date and modification date can be retrieved from row X3 of the Files table 1702. However, to retrieve the size of File3, the Document table 1704
Must access row Y2. To retrieve the priority information for File3, it is necessary to access the row Q1 of the E-mail table 1706.

To facilitate the retrieval of various attribute values belonging to a file, the rows containing these attributes are linked together. In the illustrated example, the link is "Derived
It is stored in the column labeled “Row ID”. The value stored in the Derived Row ID column of the row for a particular file in the table for a particular class points to the row for that particular file that exists in the table for the subclass of that particular class. For example, the Derived Row ID column of Files table row X3 for File3 contains the value Y2. Y2 is Document table 1704
RowID of the row for File3 in. Similarly, Derived Ro in Document line Y2
The wID field contains the value Q1. Q1 is the RowID of the row for File3 in the E-mail table 1706.

In the illustrated embodiment, the link between the lines for a particular file is unidirectional, going from the line in the table for the parent class to the line in the table for the subclass. These one-way links facilitate the search starting from the row in the base table (ie the file table), which is true under most conditions. However, if the starting point of the search is a row in another table,
The related row in the parent class table cannot be located by the link. FileID of the file of interest, looking for these related lines
These tables may be searched based on

For example, suppose the user wants to search row Y2 of the Document table 1704 and find all other attribute values for File3. The row containing the attribute value specific to E-mail may be found by following the pointer in the Derived Row ID column of row Y2, which points to row Q1 in E-mail table 1706. However, to find the remaining attributes, the Files table 1702
Based on FileID F3. Such a search would result in finding row X3, which contains the remaining attribute values of File3.

[0232] According to an alternative embodiment, the links between related lines include all related lines.
It may be implemented in a way that makes it possible to confirm its location without a FileID lookup. For example, each class table may also have a Parent RowID column that contains the RowID of the related row in the parent class table. Therefore, Docum
The Parent Row ID column for the row Y2 of the ent table 1704 is the Files table 1702.
Will point to row X3 in. Alternatively, the last row in the chain of one-way links may include a pointer back to the relevant row in the Files table. Yet another option involves providing for each class table a column containing a pointer back to the relevant row in the Files table. Thus, row R1 of Text table 1708 and row Y3 of Document table 1704 will both contain pointers back to row X4 of Files table 1702.

Subclass Registration As mentioned above, a mechanism is provided to extend the file system class hierarchy by registering a new class. In general, the information provided in the class registration process includes data identifying the parent class of the new class and data describing the attributes added by the new class. Optionally, the data may also include data used to identify new methods that can be performed on instances of the new class.

Registration information may be provided to the file system using any of a number of techniques. For example, the user may be presented with a graphical user interface that includes icons representing all of the registered classes, and the user operates the controls represented by the user interface to (1) create one of the new classes. Select it as the parent of the class and (2) name the new class,
3) Additional attributes may be defined for the new class, and (4) New methods may be defined for the new class. Alternatively, the user may provide the file system with a file containing registration information for the new class. The file system parses the file to identify and extract information, and based on that information creates a class file for the new class.

According to one embodiment of the present invention, the class registration information is Extensible Markup Language.
It is brought to the file system in the form of (XML) files. XML format is www.
oasis-open.org/cover/xml.htm1 # Explained in detail in contents and the sites listed there. Generally, the XML language includes tags that name fields and mark the beginning and end of fields and the values for these fields. For example, an XML document containing registration information for the "Folder" file class might contain the following information:

<Typename> folder </ typename><inherits_from> files </ inherits_from><dbi_classname> my_folder_methods </ dbi_classname><prop_def><name> max_children </ name><type> integer </ type></prop_def> In response to receiving this file class registration document, the file system creates a table for the new class Folder. The new table created in this way contains a column for each of the attributes defined in the registration information. In this example, only the max_children attribute is defined. max_ch
The data type specified for the ildren attribute is "integer". Therefore, Fo
The lder table is created with the max_children column holding an integer value. In addition to the attribute name and type, various other information may be provided for each attribute. For example, the registration information may indicate a range or maximum length for the attribute value, indicating whether the column should be indexed or whether the column should be unique or referentially constrained. Good.

Registration information also includes information about any methods supported by the new class file. According to one embodiment, the new methods are identified by identifying the files that contain the routines associated with these methods. According to one embodiment, the routines associated with each file class are implemented in the JAVA (R) class. If the first file class is a subclass of the second file class, the JAVA (R) class that realizes the method associated with the first file class is the JAVA (R) class that realizes the method of the second file class. Is a subclass of.

In the XML example given above, the dbi_classname field of the registration information identifies the JAVA (R) class file for the Folder file class. Specifically, the registration information is the file name "my_folder_methods" for the dbi_classname field.
And show that the my_folder_methods JAVA (R) class implements a routine for the non-inherited methods of the Folder class. Since the Folder class is a subclass of the Files class, the my_folder_methods class is a subclass of the JAVA (R) class that implements the method for the Files class. Therefore, my_fold
The er_methods class will inherit the Files method.

In addition to defining new methods that are not supported by the parent file class, routines for child file classes can override the implementations of the methods defined in the parent class. For example, the Files class shown in Figure 16 provides a "remember" method. The Folder class inherits its storage method. However, the implementation of the storage method provided for the Files class may not be the implementation needed to store folders. Therefore, the Folder class may provide its own implementation of the storage method, which overrides the implementation provided by the Files class.

Determining the Class of a File When a file system is asked to perform an operation on a file, the file system calls a routine that implements the requested operation on the particular class of file to which the file belongs. As mentioned above,
The same operation may be implemented differently for different file classes, for example when a subclass overrides the implementation provided by its parent class. That is, to ensure that the correct operation is performed, the file system must first identify the class of file on which the operation should be performed.

For files already stored in the file system, the task of identifying the class of a file may be trivial. For example, in the example shown in FIG. 17, the Files table 1702 includes, for any given row, a Class column that stores data indicating the class of the file associated with that row. Therefore, when a request to perform a "move" operation on File3 is received, the Class column of row X3 is examined to determine that File3 is of E-mail type. This should implement the "move" E-mail realization. The "move" E-mail realization is the realization provided to the E-mail file class if the E-mail file class overrides its inherited "move" method realization. Otherwise, the "move" E-mail realization is the realization inherited by the E-mail class.

The task of identifying the class of a file can be more difficult if the file is not already stored in the file system. For example, when the file system is asked to store a file that no longer exists in the file system,
The file system cannot make a class decision by examining the file table. Under such conditions, various techniques may be used to identify the type of file. According to one embodiment, the type of file may be explicitly provided in the file operation request. For example, if the request was made in response to a command issued via the operating system command line, one of the command-line arguments may be used to indicate the file type of the file. Good. For example, the command is "move
a: \ mydocs \ file2c: \ yourdocs / class = document "may be input.

Another technique for determining the class of a file involves determining the class based on the information contained in the name of the file. For example, all files with an extension (eg doc.wpd.pwp) may all be treated as members of a particular file class (eg Document). Therefore, when the file system is required to perform operations on these files, the method implementation associated with that particular file class is used.

Yet another technique for determining the class of a file involves determining the class based on the location of the file in the file system hierarchy. For example, all files created within a particular directory or set of directories can be presumed to belong to a particular file class regardless of how the files are named. These and other approaches may be combined in various ways. For example, a file with a certain extension is
If the file is not stored in the directory associated with the second class, it can be treated as a member of the first class. If the file is stored in a directory associated with a second class, then the file is a second class unless the file operation request explicitly identifies that the file is a member of another file class. Treated as a member of.

Hardware Appearance FIG. 18 is a block diagram showing a computer system 1800 in which an embodiment of the present invention can be implemented. Computer system 1800 includes a bus 1802 or other communication mechanism for communicating information, and a processor 1804 coupled with bus 1802 for processing information. Computer system 1800 also includes main memory 18 such as random access memory (RAM) or other dynamic storage.
06, which is coupled to bus 1802 and stores information and instructions to be executed by processor 1804. Main memory 1806 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 1804. Computer system 1800 further includes a read only memory (ROM) 1808 or other static storage device coupled to bus 1802 for storing static information and instructions for processor 1804. A storage device 1810, such as a magnetic disk or optical disk, is provided and is coupled to bus 1802 for storing information and instructions.

Computer system 1800 may be coupled via bus 1802 to a display 1812, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 1814, which includes alphanumeric keys and other keys, is coupled to bus 1802 to communicate information and command selections to processor 1804. Another type of user input device is a cursor control 1816, such as a mouse, trackball or cursor direction keys, which communicates direction information and command selections to the processor 1804 and controls cursor movement on the display 1812. This input device typically has two degrees of freedom in two axes, a first axis (eg x) and a second axis (eg y), which allows the device to specify a position in a plane. to enable.

The present invention provides a computer system 1 for implementing the techniques described herein.
Regarding the use of 800. According to one embodiment of the invention, these techniques are implemented by computer system 1800 in response to processor 1804 executing one or more sequences of one or more instructions contained in main memory 1806. . Such instructions may be read into main memory 1806 from another computer-readable medium, such as storage device 1810. Main memory 180
Execution of the sequences of instructions contained in 6 will cause processor 1804 to perform the process steps described herein. In alternative embodiments, wiring circuitry may be used in place of or in combination with software instructions to implement the invention. Thus, embodiments of the present invention are not limited to any particular combination of hardware circuitry and software.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 1804 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1810. Volatile media includes dynamic memory, such as main memory 1806. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1802. Transmission media may also take the form of acoustic or light waves, such as those generated in radio and infrared data communications.

Common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape or any other magnetic media, CD-ROM, all other optical media, perforated cards, paper tape. , All other physical media with hole patterns, RAM, PROM and EPROM, FLASH-
It includes all EPROMs, other memory chips or cartridges, carrier waves or any other computer-readable medium as described below.

Various forms of computer readable media may be included in a processor 1804 for execution.
To one or more sequences of one or more instructions. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. Computer system 1
A modem included in 800 can receive data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. The infrared detector can receive the data carried in the infrared signal and the appropriate circuitry can output the data on bus 1802. Bus 1802 carries data to main memory 1806 from which processor 1804 fetches and executes instructions. The instructions received by main memory 1806 may optionally be stored on storage device 1810 either before or after execution by processor 1804.

Computer system 1800 also includes a communication interface 1818 coupled to bus 1802. Communication interface 1818 provides bidirectional data communication coupled to a network link 1820 connected to local network 1822. For example, communication interface 1818 may be a modem or integrated services digital network (ISDN) card that provides a data communication connection to a corresponding type of telephone line. As another example, communication interface 1818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be realized. In any such implementation, communication interface 1818 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Network link 1820 typically provides data communication to other data devices via one or more networks. For example, the network link 1820 is connected to the host computer 1 via the local network 1822.
A connection may be provided to 824 or to a data device operated by an Internet Service Provider (ISP) 1826. The ISP1826
Provides data communication services over the world wide packet data communication network now commonly referred to as the "Internet" 1828. Both local network 1822 and Internet 1828 use electrical, electromagnetic or optical signals that carry digital data streams. Signals over various networks and signals over network link 1820 and through communication interface 1818 for communicating digital data with computer system 1800 are exemplary forms of carrier waves carrying information.

The computer system 1800 is a network, a network link 182.
0 and communication interface 1818, messages can be sent and data can be received, including program code. In the Internet example, server 1830 may send the requested code for the application program via Internet 1828, ISP 1826, local network 1822 and communication interface 1818. According to this invention,
One such downloaded application implements the approach described herein.

The received code may be received and executed by processor 1804 and / or stored in storage device 1810 or other non-volatile storage for later execution. In this manner, computer system 1800 may obtain application code in the form of carrier waves.

In the above specification, the present invention has been described with reference to specific embodiments thereof. However, it will be apparent that various changes and modifications may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are accordingly to be regarded in an illustrative sense and not in a limiting sense.

[Brief description of drawings]

FIG. 1 is a block diagram showing how data is stored in a conventional application through a file system provided by an operating system.

FIG. 2 is a block diagram showing how data is stored through a database API provided by a database system in a conventional database application.

FIG. 3 is a block diagram illustrating a system in which the same data set is accessible through various interfaces including a database API and an OS file system API.

FIG. 4 is a block diagram showing translation engine 308 in greater detail.

FIG. 5 is a block diagram showing a hierarchical index.

FIG. 6 is a block diagram showing a file hierarchical structure that can be emulated by a hierarchical index.

FIG. 7 is a block diagram illustrating a file table that can be used to store files in a relational database, according to one embodiment of the invention.

FIG. 8 is a flowchart showing steps for deriving a path name using a hierarchical index.

FIG. 9 is a block diagram showing the database file server in more detail.

FIG. 10 is a block diagram of a hierarchical index that includes an entry for a stored query directory.

FIG. 11 is a block diagram of a file table containing a row for a stored query directory.

FIG. 12 is a block diagram showing a file hierarchy structure including a stored query directory.

FIG. 13 is a block diagram showing a file hierarchical structure.

FIG. 14 is a block diagram illustrating how the file hierarchy shown in FIG. 13 is updated in response to a document update in accordance with one embodiment of the versioning techniques described herein.

FIG. 15 is a block diagram showing how the file hierarchy shown in FIG. 13 is updated in response to a document moving from one folder to another according to one embodiment of the versioning techniques described herein. It is a figure.

FIG. 16 is a block diagram showing a class hierarchy structure of a file class according to an embodiment of the present invention.

FIG. 17 is a block diagram showing a relationship table used in the database-implemented file system that implements the file class hierarchical structure of FIG. 16 according to an embodiment of the present invention.

FIG. 18 is a block diagram illustrating a computer system in which embodiments of the present invention may be implemented.

─────────────────────────────────────────────────── ─── Continued front page    (31) Priority claim number 09 / 571,060 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 571,492 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 571,496 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 571,508 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 571,568 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (31) Priority claim number 09 / 571,696 (32) Priority date May 15, 2000 (May 15, 2000) (33) Priority claiming countries United States (US) (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE), OA (BF, BJ , CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, K E, LS, MW, MZ, SD, SL, SZ, TZ, UG , ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, BZ, C A, CH, CN, CR, CZ, DE, DK, DM, DZ , EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, K G, KR, KZ, LC, LK, LR, LS, LT, LU , LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, RO, RU, SD, S E, SG, SI, SK, SL, TJ, TM, TR, TT , TZ, UA, UG, UZ, VN, YU, ZA, ZW F-term (reference) 5B075 ND02 QT06                 5B082 EA01 GA08

Claims (116)

[Claims] 1. A method of accessing data stored in a database, the method comprising the step of an application making one or more calls to an operating system to access a file. The system includes a routine that implements an operating system file system, the one or more calls are made to the routine that implements the operating system file system, and the database is responsive to the one or more calls. Issuing one or more database commands to a database server that manages the database, and the database server executing the database commands to retrieve the data from the database. Including a flop, and generating the file from the data, and providing the file to the application method. 2. The method of claim 1, wherein the step of providing the file to the application is performed by the routine implementing the operating system file system. 3. The step of issuing one or more database commands in response to the one or more calls includes one or more of the routines implementing the operating system file system being executed by the operating system. Sending one or more I / O commands to a protocol server configured to operate, the protocol server converting the one or more I / O commands into one or more DB file system commands The method of claim 1, comprising the steps of: issuing a database command or commands in response to the DB file system command or commands. 4. A computer readable medium carrying instructions for accessing data stored in a database, the computer readable medium comprising one or more operating systems for an application to access a file. Instructions for performing the steps of making a call, the operating system includes a routine that implements an operating system file system, the one or more calls are made to the routine that implements the operating system file system, And further issuing one or more database commands to a database server managing the database in response to the one or more calls; Comprising the steps of retrieving the data from the database by executing the Sukomando, and generating the file from the data, and providing the file to the application, instructions for performing the computer-readable media. 5. The computer-readable medium of claim 4, wherein the step of providing the file to the application is performed by the routine that implements the operating system file system. 6. The step of issuing one or more database commands in response to the one or more calls includes one or more of the routines implementing the operating system file system being executed by the operating system. Sending one or more I / O commands to a protocol server configured to operate, the protocol server converting the one or more I / O commands into one or more DB file system commands The computer-readable medium of claim 4, comprising the steps of: issuing the one or more database commands in response to the one or more DB file system commands. 7. A method of performing a file operation, the method including the step of opening a file system interface to an application, the file system interface including routines for saving and retrieving files. Receiving a call to perform a plurality of file operations through the file system interface, the plurality of file operations, if all file operations of the plurality of file operations complete without failure, Making all changes made by any of the file operations permanent, if any of the plurality of file operations fails. The step of disabling all changes made by all of the plurality of file operation, by performing, and a step of performing a single transaction,
Method. 8. The method of claim 7, wherein the plurality of file operations include at least one of a first file operation on a first file and a second file operation on a second file. 9. The method of claim 7, wherein the plurality of file operations comprises a series of write operations on a single file. 10. The step of performing the plurality of file operations comprises:
8. The method of claim 7, comprising issuing one or more database statements to a database server, the database server executing the database statements to perform the plurality of file operations. 11. The method of claim 9, wherein the plurality of write operations correspond to transferring the single file across a network connection for storage in a database. 12. The method of claim 7, wherein the call is made by a protocol server in response to receiving the command by the protocol server. 13. The method of claim 12, wherein the protocol server emulates a device driver interface and the command is sent by the operating system to the protocol server. 14. A computer readable medium carrying instructions for performing file operations, the computer readable medium comprising instructions for performing a step of opening a file system interface to an application, said file system. The interface includes routines for saving and retrieving files, further comprising receiving calls to perform multiple file operations through the file system interface, the multiple file operations, if the multiple file operations are performed. If all file operations of the operations are completed without failure, the step of making all the changes made by the plurality of file operations permanent is If any file operation of the file operations fails, undoing all changes made by all of the plurality of file operations, thereby performing as a single transaction. A computer-readable medium containing instructions. 15. The computer-readable computer-readable medium of claim 14, wherein the plurality of file operations includes at least one of a first file operation on a first file and a second file operation on a second file. Medium. 16. The computer-readable medium of claim 14, wherein the plurality of file operations comprises a series of write operations on a single file. 17. The steps of performing the plurality of file operations include:
15. The computer-readable medium of claim 14 including the step of issuing one or more database statements to a database server, the database server executing the database statements to perform the plurality of file operations. 18. The computer-readable medium of claim 16, wherein the plurality of write operations correspond to transferring the single file over a network connection for storage in a database. 19. The computer-readable medium of claim 14, wherein the call is made by a protocol server in response to receiving the command. 20. The computer-readable medium of claim 19, wherein the protocol server emulates a device driver interface and the command is sent by the operating system to the protocol server. 21. A method of responding to a file request received via a file system interface, the method comprising: building an association between a file identifier and a query; and a file associated with the file identifier. Receiving a request via the file system interface for executing a query to generate a set of data in response to the request; and generating the contents of the file based on the set of data. And, providing the file via the file system interface. 22. The file is a directory, the request is for a list of files in the directory, and the step of generating the content includes determining which file is the directory based on the set of data. 22. The method of claim 21, performed by determining if 23. The query selects a set of database records, and providing the file comprises presenting a database record from the set of database records as a file in the directory.
23. The method of claim 22. 24. The method of claim 21, wherein the file is a document, and the step of generating the content comprises building at least a portion of the document from the data set. 25. The method of claim 24, wherein generating the content comprises combining the portion constructed from the data set with a previously stored portion of the document to create the document. The method described. 26. Determining which files are in the directory based on the set of data includes determining one or more directories in the directory, the method comprising: 23. The method of claim 22, further comprising determining which files are in the one or more directories based on the set. 27. The query includes a group by clause that identifies a group by key, the one or more directories corresponding to values for the group by key. Item 26. The method according to Item 26. 28. Receiving a request for a file associated with the file identifier through the file system interface, the operating system receiving the request from an application and sending a message in response to the request; Receiving a message from the operating system, executing the query to generate a data set includes issuing a database command to a database server in response to the message, the file system Providing the file through an interface, the protocol server providing the file to the operating system, and Computing system and providing the file to the application, The method of claim 21. 29. A computer readable medium carrying instructions for responding to a file request received through a file system interface, the computer readable medium establishing an association between a file identifier and a query. Receiving, via the file system interface, a request for a file associated with the file identifier, in response to the request, executing the query to generate a data set, based on the data set A computer-readable medium comprising instructions for performing the steps of: generating the contents of the file; and providing the file via the file system interface. 30. The file is a directory, the request is for a list of files in the directory, and the step of generating the content includes determining which file is the directory based on the set of data. 30. The computer-readable medium of claim 29, which is performed by determining if it is in. 31. The query selects a set of database records, and the step of providing the file comprises presenting a database record from the set of database records as a file in the directory.
The computer-readable medium of claim 30. 32. The computer-readable medium of claim 29, wherein the file is a document and the step of generating the content comprises constructing at least a portion of the document from the data set. 33. The method of claim 32, wherein generating the content comprises combining the portion constructed from the data set with a previously stored portion of the document to create the document. The computer-readable medium described. 34. Determining which files are in the directory based on the set of data includes determining one or more directories in the directory, the computer-readable medium comprising: 31. The computer-readable medium of claim 30, further comprising determining which files are in the one or more directories based on the data set. 35. The computer-readable medium of claim 34, wherein the query includes groups by phrase identifying groups by key, and wherein the one or more directories correspond to values for groups by key. 36. Receiving a request for a file associated with the file identifier through the file system interface, the operating system receiving the request from an application and sending a message in response to the request; Receiving a message from the operating system, executing the query to generate a data set includes issuing a database command to a database server in response to the message, the file system Providing the file through an interface, the protocol server providing the file to the operating system, and Computing system and providing the file to the application, a computer-readable medium of claim 29. 37. A method of managing files in a computer system, the method comprising establishing an association between a type of file system operation, a file and an entity of interest, said type of file. Detecting when a system operation is performed on the file, and the interested entity in response to detecting that a file system operation of the type was performed on the file. Sending a message to. 38. The message comprises data indicating that a file system operation of the type was performed on the file.
7. The method according to 7. 39. The method of claim 37, wherein the file is a directory and the type of file system operation is to insert another file into the directory. 40. Building an association between the type of file system operation, a file, and an entity of interest.
38. The method of claim 37, performed in response to the file being stored in a particular directory. 41. Responsive to the file being removed from the particular directory, further comprising the step of deleting the association between the type of file system operation, the file, and the entity of interest. ,
The method of claim 40. 42. The file is stored in a database, and the method comprises a file operation of the type for the file by issuing one or more database commands to a database server managing the database. 38. The method of claim 37, including the step of performing. 43. Building an association between the type of file system operation, a file, and an entity of interest.
Storing a database record in the database indicating that a message should be sent to the interested entity when a file system operation of the type is performed on the file.
43. The method of claim 42. 44. A computer readable medium for managing files in a computer system, the computer readable medium establishing an association between a type of file system operation, a file, and an entity of interest. Detecting when a file system operation of the type is performed on the file; and in response to detecting that a file system operation of the type is performed on the file, Sending a message to an entity of interest. 45. The message includes data indicating that a file system operation of the type was performed on the file.
4. A computer-readable medium according to item 4. 46. The computer-readable medium of claim 44, wherein the file is a directory and the type of file system operation is to insert another file into the directory. 47. Building an association between the type of file system operation, the file, and the entity of interest.
The computer-readable medium of claim 44, which is done in response to the file being stored in a particular directory. 48. Responsive to the file being removed from the particular directory, further comprising the step of deleting the association between the type of file system operation, the file, and the entity of interest. ,
The computer-readable medium of claim 47. 49. The file is stored in a database and the computer-readable medium is of the type for the file by issuing one or more database commands to a database server that manages the database. Including steps to perform file operations,
The computer-readable medium of claim 44. 50. Building an association between the type of file system operation, the file, and the entity of interest.
Storing a database record in the database indicating that a message should be sent to the interested entity when a file system operation of the type is performed on the file.
The computer-readable medium of claim 49. 51. A method for implementing a file system for storing electronic files, the method comprising: constructing a first file class comprising a first set of methods; Receiving data identifying a second file class that includes the method, and in response to a request to perform an operation on the file, the file system identifying the class associated with the file. And, if the file is associated with the first class, calling a first routine associated with the first class to perform the operation; Associated with the second class to perform the operation, if associated with the second class Invoking a second routine that is executing; 52. The data identifying the second file class specifies that the second file class is a subclass of the first file class and the file system is the second file class. 52. The method of claim 51, causing a class to inherit the first set of methods from the first file system. 53. The first routine provides a first realization of the operation and the second routine overrides the first realization for files associated with the second file class. 53. The method of claim 52, providing a second implementation of the operation. 54. A method for implementing a file system for storing electronic files, the method comprising constructing a first file class including a first set of attributes and a first set of methods. Receiving data identifying a second file class including a second set of attributes and a second set of methods, the file system comprising: the first set for files of the first file class; Storing the attribute values of the attributes of the second set of attributes for the files of the second file class and the attributes of the first set of attributes of the second set of attributes. Different, way. 55. The method of claim 54, wherein the file system stores attribute values of files stored in the file system in a relational table managed by a database server. 56. The second file class is a subclass of the first file class, and the relationship table includes a first relationship table storing attribute values of the first set of attributes, 56. The method of claim 55, wherein the relationship table comprises a second relationship table that stores attribute values for attributes included in the second set of attributes and not included in the first set of attributes. 57. The file system stores a specific file associated with the second file class, for the specific file, the file system stores a specific file of the first relationship table. In a row, storing attribute values of the first set of attributes, for the particular file, the file system is in a particular row of the second relationship table, in the second set of attributes. 57. The method of claim 56, storing attribute values for attributes that are not included in the first set of attributes. 58. The method of claim 57, wherein the particular row of the first relationship table comprises a link to the particular row of the second relationship table. 59. A computer-readable medium carrying instructions for implementing a file system for storing electronic files, said computer-readable medium constructing a first file class comprising a first set of methods. And a step of receiving data identifying a second file class including a second set of methods, the file system associating with the file in response to a request to perform an operation on the file. Identifying the class being assigned, and if the file is associated with the first class, calling a first routine associated with the first class to perform the operation. Step, if the file is associated with the second class, the operation Calling a second routine associated with the second class to perform a computer program, and executing instructions for performing a computer readable medium. 60. The data identifying the second file class specifies that the second file class is a subclass of the first file class and the file system is the second file class. 60. The computer-readable medium of claim 59, causing a class to inherit the first set of methods from the first file system. 61. The first routine provides a first realization of the operation and the second routine overrides the first realization for a file associated with the second file class. The computer-readable medium of claim 60, which provides a second implementation of the operation. 62. A computer readable medium carrying instructions for implementing a file system for storing electronic files, the computer readable medium including a first set of attributes and a first set of methods. Constructing a first file class, receiving data identifying a second file class including a second set of attributes and a second set of methods, the file system comprising: Storing the attribute values of the first set of attributes for the files of the second file and the attribute values of the second set of attributes for the files of the second file class. A computer-readable medium, wherein the attributes of the first set are different from the attributes of the second set. 63. The computer-readable medium of claim 62, wherein the file system stores attribute values of files stored in the file system in a relational table managed by a database server. 64. The second file class is a subclass of the first file class, and the relationship table includes a first relationship table storing attribute values of the first set of attributes, 64. The computer-readable medium of claim 63, wherein the relationship table includes a second relationship table that stores attribute values for attributes that are included in the second set of attributes and not included in the first set of attributes. . 65. The file system stores a specific file associated with the second file class, and for the specific file, the file system stores a specific file in the first relationship table. In a row, storing attribute values of the first set of attributes, for the particular file, the file system is in a particular row of the second relationship table, in the second set of attributes. 66. The computer-readable medium of claim 64, storing attribute values for attributes that are not included in the first set of attributes. 66. The computer-readable medium of claim 65, wherein the particular row of the first relationship table includes a link to the particular row of the second relationship table. 67. A method of accessing data stored in a database, the method comprising: receiving a request from an application for a storage file currently stored in the database, the storage file comprising a first Issuing one or more database commands associated with a file type and further retrieving data associated with the storage file from the database, the plurality of database commands based on a first set of selection criteria. Selecting one renderer from the renderers, and using the renderer to generate an outbound file from the data, the outbound file corresponding to a second file type, and further comprising: The orientation file to the application Including the step of the method. 68. The method further comprises determining that the application supports multiple file types, wherein the renderer selects from the multiple file types based on a second set of selection criteria. 68. The method of claim 67, selecting two file types. 69. The method further comprises determining the value of one or more attributes of the storage file, the second set of selection criteria being selection criteria based on the values of the one or more attributes. 69. The method of claim 68, including. 70. The step of determining that the application supports multiple file types includes the step of determining the application's identity and reading data from the database that is indicative of the application's capabilities. 69. The method of claim 68. 71. The method of claim 67, wherein the first set of selection criteria comprises file type-based selection criteria of the storage file. 72. The first file type is the same file type as the second file type, and wherein the step of generating the outbound file includes a plurality of columns of one or more tables in the database. 68. The method of claim 67, including the step of combining the values from to a single file. 73. Receiving an original file of the first data type before receiving the request; parsing the original file to generate one or more metadata values for the original file. Storing the original file as the storage file in the database, storing the one or more metadata values in the database in a manner that associates the one or more metadata values with the storage file. 68. The method of claim 67, further comprising the steps of: and. 74. The step of receiving the original file is performed by receiving data transmitted according to a first protocol, and the step of providing the outbound file to the application transmits data according to a second protocol. 74. The method of claim 73, wherein the first protocol is different from the second protocol. 75. The first protocol is an I / O protocol supported by a first operating system and the second protocol is an I / O protocol supported by a second operating system. 75. The method of claim 74, wherein: 76. The method of claim 74, wherein at least one of the first protocol and the second protocol belongs to a set of protocols consisting of HTTP, FTP, IMAP4 and POP3. 77. A computer readable medium carrying instructions for accessing data stored in a database, the computer readable medium receiving a request from an application for a storage file currently stored in the database. The storage file is associated with a first file type, and further includes one or more database commands for retrieving the data associated with the storage file from the database. Performing a publishing step, selecting a renderer from a plurality of renderers based on a first set of selection criteria, and generating an outbound file from the data using the renderer. Including instructions, said outward Airu corresponds to a second file type, further comprising instructions for performing the step of providing the outwardly file to the application, computer-readable media. 78. The computer-readable medium further comprises instructions for performing steps for determining that the application supports multiple file types, the renderer based on a second set of selection criteria. 78. The computer-readable medium of claim 77, selecting the second file type from the plurality of file types. 79. The computer-readable medium further comprises instructions for performing the step of determining the value of one or more attributes of the storage file, the second set of selection criteria being the one or more of the one or more. 79. The computer-readable medium of claim 78, comprising selection criteria based on the value of an attribute of. 80. The step of determining that the application supports multiple file types includes the step of determining the application's identity and reading data from the database indicating the application's capabilities. 79. The computer-readable medium of claim 78. 81. The computer-readable medium of claim 77, wherein the first set of selection criteria comprises selection criteria based on a file type of the storage file. 82. The first file type is the same file type as the second file type, and wherein the step of generating the outbound file includes a plurality of columns of one or more tables in the database. 78. The computer-readable medium of claim 77, including the step of combining the values from to a single file. 83. Receiving an original file of the first data type prior to receiving the request; parsing the original file to generate one or more metadata values for the original file. Storing the original file as the storage file in the database, storing the one or more metadata values in the database in a manner that associates the one or more metadata values with the storage file. 78. The computer-readable medium of claim 77, further comprising the steps: and instructions for performing. 84. The step of receiving the original file is performed by receiving data transmitted according to a first protocol, and the step of providing the outbound file to the application transmits data according to a second protocol. 84. The computer-readable medium of claim 83, wherein the first protocol is different from the second protocol. 85. The first protocol is an I / O protocol supported by a first operating system and the second protocol is an I / O protocol supported by a second operating system. 85. The computer-readable medium of claim 84, which is. 86. The computer-readable medium of claim 84, wherein at least one of the first protocol and the second protocol belongs to a set of protocols consisting of HTTP, FTP, IMAP4 and POP3. 87. A method of managing a version of a file in a file system, the method comprising: in response to creating a new version of a file, creating a new version of the directory that is derived from the directory. , The different versions of the versioned directory are associated with different time points, and the version of the file derived from a particular version of the versioned directory is added to the versioned directory. Maintaining a link between the files in the file system to reflect the associated time points. 88. Determining a selected time point for which a file should reflect for a particular operation, and a particular version of the directory from a plurality of versions of the directory to the particular version of the directory. Selecting based on a version being associated with the selected time point, and following links from the selected version of the directory to locate one or more files involved in the operation. 88. The method of claim 87, further comprising: locating. 89. The method includes the step of receiving an input indicating a movement of a particular file from a version of a first directory to a first version of a second directory, the method of claim One version includes a first set of zero or more files other than the particular file, and a first version of the second directory is zero or more than one file other than the particular file. Including a second set of files, maintaining the link in response to the input, creating a second version of the first directory; The first set of zero or more files in the first directory without building as a member of the second version of the directory. Building a second version of the second directory, the specific file and the second set of zero or more files in the second directory. 88. The method of claim 87, comprising the steps of: building as a member of the second version of a directory. 90. A method of managing a version of a file in a file system, the method comprising providing a mechanism for tagging a version of a file that is not overwritten; Determining whether the first version of the file is tagged in response to updating the file, and if the first version of the file is tagged, the file Storing said second version of said file while retaining said first version of said file, said second version of said file if said first version of said file is not tagged. Responsive to storing the version, deleting the first version of the file. Law. 91. The method includes reversing a file hierarchy to locate the first version of a file and determining whether the first version of the file is tagged. Determining whether the file was inverted to locate the first version of the file, and reversed to locate the first version of the file If the file was tagged, storing the second version of the file while retaining the first version of the file, inverted to locate the first version of the file If the file is untagged, store the second version of the file In response to the comprising the step of deleting the first version of the file, the method of claim 90. 92. The first version of the file is stored in a first version of a specific directory, the first version of the specific directory being one or more than the file. Storing a second version of the file while retaining the first version of the file, the method including: creating a second version of the specific directory; Building a file as a member of the second version of the specific directory; and maintaining the first version of the specific file as a member of the first version of the specific directory. While adding the second version of the file to the second directory of the specific directory. The step of constructing as a member of the, Version, including method of claim 90. 93. The method includes receiving an update to a first version of a particular file, wherein the first version of the particular file is first to a particular directory.
Stored in a version of the particular directory, the first version of the particular directory includes one or more files other than the particular file, and maintaining the link is responsive to the update. Creating a second version of the specific directory, creating a second version of the specific file, adding the one or more files to a member of the second version of the specific directory And maintaining the first version of the particular file as a member of the first version of the particular directory while maintaining the second version of the particular file as Building as a member of said second version of a specific directory. 88. The method of claim 87, which comprises a pop up. 94. A method of maintaining a version of a file in a file system, wherein the method is responsive to a change made to the first version of the file to meet a first set of criteria. Determining if the first set of criteria is met, creating a second version of the file while retaining the first version of the file, and an ancestor file. Satisfying the second set of criteria, creating a new version of each ancestor file above the file in the file hierarchy. 95. Receiving user input identifying that one or more files in the file system are tagged, and providing data indicating that the one or more files are tagged. Storing in a file system, the step of determining whether the first set of criteria is met includes determining whether the first version of the file is tagged. 95. The method of claim 94, wherein the first set of criteria comprises: tagging the first version of the file. 96. The method of claim 94, further comprising associating the file with a project, wherein the second set of criteria includes that the ancestor file belongs to the project. 97. The file system comprises one or more files belonging to a second project, the method comprising: a view of the file system,
A file belonging to the project appears to have existed at a first time point therein, and the one or more files belonging to the second project differ from the first time point in a second time point. 97. The method of claim 96, further comprising allowing a user to use a view that appeared to exist at a time point. 98. Reversing the file hierarchy based on links between files in the file system through the view, and wherein the view causes the source and target files to be at the same time point during the reversing. 98. The method of claim 97, further comprising following a link having the source file and the target file only if they appear to be. 99. The method of claim 95, further comprising, in response to creating the second version of the file, deleting an untagged third version of the file. Method. 100. The step of deleting the third version of the file comprises the step of: the creation of the second version of the file causing the number of untagged versions of the file to exceed a threshold maximum number. 100. The method of claim 99, which is performed in response to being detected. 101. The method of claim 97, further comprising marking a link in the file system indicating whether the source and target files associated with the link belong to the same project. . 102. A computer readable medium carrying instructions for managing versions of files in a file system, the computer readable medium deriving from a directory in response to creating a new version of a file. Instructions for performing the steps of creating a new version of the directory, the different versions of the versioned directory being associated with different time points, and further from the particular version of the versioned directory. Instructions for performing the step of maintaining links between the files in the file system such that the version of the derived file reflects the time point associated with the versioned directory. Including computer readable media . 103. Determining a selected time point for which a file should reflect for a particular operation, and a particular version of the directory from a plurality of versions of the directory to the particular version of the directory. Selecting based on a version being associated with the selected time point, and following links from the selected version of the directory to locate one or more files involved in the operation. 103. The computer-readable medium of claim 102, further comprising locating steps, and instructions for performing. 104. The computer-readable medium is a first of a particular file.
A first version of the first directory, the first version of the first directory being other than the particular file. A first set of zero or more files of the second directory, the first version of the second directory including a second set of zero or more files other than the particular file, the link Maintaining a second version of the first directory in response to the input; constructing the specific file as a member of the second version of the first directory. Without the first set of zero or more files as members of the second version of the first directory. Building a second version of the second directory, the specific file and the second set of zero or more files in the second directory of the second directory. 103. The computer-readable medium of claim 102, including the steps of building as a member of a version of the. 105. A computer-readable medium carrying instructions for managing versions of a file in a file system, the computer-readable medium providing a mechanism for tagging a version of a file that is not overwritten. Responsive to updating the file to a first version, determining whether the first version of the file is tagged, and tagging the first version of the file with a tag. Storing the second version of the file while retaining the first version of the file, if the first version of the file is untagged In response to storing the second version of the file, the first version of the file The step of deleting down, including instructions for performing the steps, the performing, computer-readable media. 106. The computer readable medium includes instructions for performing the steps of reversing a file hierarchy to locate the first version of a file, the first version of the file being tagged with a tag. Determining if it has been tagged to the file that has been reversed to locate the first version of the file, and the first of the file. Storing the second version of the file while retaining the first version of the file if the inverted file was tagged to locate the version of the file, the second version of the file If the reversed file is not tagged to find the 1 version, Comprising the step of deleting the first version of the file in response to storing the second version of the file, a computer-readable medium of claim 105. 107. The first version of the file is stored in a first version of a specific directory, the first version of the specific directory including one or more files other than the file. Storing a second version of the file while retaining the first version of the file, the method including: creating a second version of the specific directory; Building a file as a member of the second version of the specific directory; and maintaining the first version of the specific file as a member of the first version of the specific directory. While replacing the second version of the file with the second version of the specific directory. Comprising the step of constructing a version of a member, a computer-readable medium of claim 105. 108. The computer-readable medium includes instructions for performing the steps of receiving an update to a first version of a particular file, the first version of the particular file being First of the directory
Stored in a version of the particular directory, the first version of the particular directory includes one or more files other than the particular file, and maintaining the link is responsive to the update. Creating a second version of the specific directory, creating a second version of the specific file, adding the one or more files to a member of the second version of the specific directory And maintaining the first version of the particular file as a member of the first version of the particular directory while maintaining the second version of the particular file as Building as a member of said second version of a specific directory. 103. The computer-readable medium of claim 102, which comprises a disc. 109. A computer-readable medium carrying instructions for maintaining a version of a file in a file system, the computer-readable medium responsive to a change made to a first version of the file. , A step of determining whether the first set of criteria is met, and if the first set of criteria is met, a second version of the file is retained while retaining the first version of the file. Creating a version, and, if the ancestor file meets a second set of criteria, creating a new version of each ancestor file above the file in the file hierarchy. A computer-readable medium containing instructions for :. 110. Receiving user input identifying that one or more files in the file system are tagged, and providing data indicating that the one or more files are tagged. And storing instructions in the file system to determine whether the first set of criteria is met by tagging the first version of the file. 110. The computer-readable medium of claim 109, comprising determining whether or not the first set of criteria is tagged, wherein the first set of criteria includes the first version of the file being tagged. 111. The method of clause 109, further comprising instructions for performing the step of associating the file with a project, wherein the second set of criteria comprises that the ancestor file belongs to the project. Computer readable medium. 112. The file system comprises one or more files belonging to a second project, the computer-readable medium being a view of the file system, wherein the files belonging to the project are the first. A view that appears to have existed at a time point, and the one or more files belonging to the second project appear to have existed at a second time point different from the first time point. 112. The computer-readable medium of claim 111, further comprising instructions for performing a step of making available to a user. 113. Reversing the file hierarchy based on links between files in the file system through the view; and during the reversing, the source and target files are at the same time point. 113. The computer-readable medium of claim 112, further comprising instructions for performing a link having the source file and the target file only if they appear to. 114. Further comprising instructions for performing a step of deleting an untagged third version of the file in response to creating the second version of the file. The computer-readable medium of claim 110. 115. The step of deleting the third version of the file comprises the step of: creating the second version of the file such that the number of untagged versions of the file exceeds a threshold maximum number. 115. The computer-readable medium of claim 114, wherein the computer-readable medium is performed in response to being detected. 116. The computer of claim 112, further comprising the step of marking the file system link to indicate whether the source and target files associated with the link belong to the same project. A readable medium.