Internet file system
14 claims: 13 independent, 1 dependent
- 1データベースに記憶されたデータにアクセスする方法であって、 該方法は、プロトコルサーバが、オペレーティングシステ ムの 1つ以上のルーチンからの、1つ以上のI/Oコマンドを受取るステップを含み、前記プロトコルサーバは、前記オペレーティングシステムで動作するよう構成されており、 前記1つ以上のルーチンは、アプリケーションから前記オペレーティングシステムへの、ファイルへアクセスするための1つ以上のコールに応答して、1つ以上のI/Oコマンドを生成しており、 該方法は、 前記プロトコルサーバが、前記1つ以上のI/Oコマンドを1つ以上のDBファイルシステムコマンドに変換するステップと、 DBファイルサーバ が、前記1つ以上のDBファイルシステムコマンドに応答して、1つ以上の 第1の データベースコマンドを、生成するとともに前記データベースを管理するデータベースサーバに対して発行するステップとを含み、 前記データベースサーバは、前記1つ以上の 第1の データベースコマンドを実行して前記データベースから 第1の データを検索し 、前 記 第1の データから生成され たファイルを第1の アプリケーションに提供 し、該方法はさらに、 第2のアプリケーションに対してDBファイルAPIを提供するステップと、 前記DBファイルサーバが、前記DBファイルAPIを介して、前記第2のアプリケーションからの1つ以上の第2のDBファイルシステムコマンドを直接受取るステップとを含み、 前記1つ以上の第2のDBファイルシステムコマンドに応答して、1つ以上の第2のデータベースコマンドが、生成されるとともに前記データベースサーバに対して発行され、 前記データベースサーバは、前記1つ以上の第2のデータベースコマンドを実行して前記データベースから第2のデータを検索し、前記第2のデータから生成されたファイルを前記第2のアプリケーションに提供する、 方法。
- 2前記ファイル を アプリケーションに提供 する処理 は、前記オペレーティングシステ ムにおける 1つ以上のルーチンによって 実行される 、請求項1に記載の方法。
- 3前記DBファイルサーバが、 前記DBファイルAPIを介して、複数のファイルオペレーションを行なうためのコールを受取るステップ を含み、前記複数のファイルオペレーションは、少なくとも、前記データベースに記憶された第1のファイルに対する第1のファイルオペレーションと、前記データベースに記憶された第2のファイルに対する第2のファイルオペレーションとを含み、該方法はさらに、 前記DBファイルサーバが、 前記複数のファイルオペレーションを、次のステップを行なうことによって、単一のトランザクションとして行なうステッ プを含 み、該次のステップは、 もし前記複数のファイルオペレーションのうちすべてのファイルオペレーションが失敗なく完了すれば、前記複数のファイルオペレーションによってなされたすべての変化を永久のものとするステップと、 もし前記複数のファイルオペレーションのうち何らかのファイルオペレーションが失敗すれば、前記複数のファイルオペレーションのすべてによってなされたすべての変化を無効にするステップとを含む、請求項 2 に記載の方法。
- 4前記複数のファイルオペレーションは、 前記データベースに記憶された 単一のファイルに対する複数の書込オペレーションを含む、請求項 3 に記載の方法。
- 5前記複数のファイルオペレーションを行なうステップは、 前記 データベースサーバに対して1つ以上のデータベースステートメントを発行するステップを含み、前記データベースサーバは前記1つ以上のデータベースステートメントを実行して前記複数のファイルオペレーションを行なう、請求項 3 に記載の方法。
- 6前記複数の書込オペレーションは、前記単一のファイルを前記データベースに記憶するためにネットワーク接続にわたって転送することに 相当 する、請求項 4 に記載の方法。
- 7前記プロトコルサーバは、デバイスドライバインターフェイス として機能 する、請求項1~ 6 のいずれか1項に記載の方法。
- 8データベースに記憶されたデータにアクセスするための命令を記憶した1つ以上のコンピュータ読取可能媒体であって、該命令は、1つ以上のプロセッサによって実行されると、以下のステップを生じさせ、 該以下のステップは、プロトコルサーバが、オペレーティングシステ ムの 1つ以上のルーチンからの、1つ以上のI/Oコマンドを受取るステップを含み、前記プロトコルサーバは、前記オペレーティングシステムで動作するよう構成されており、 前記1つ以上のルーチンは、アプリケーションから前記オペレーティングシステムへの、ファイルへアクセスするための1つ以上のコールに応答して、1つ以上のI/Oコマンドを生成しており、 該以下のステップは、 前記プロトコルサーバが、前記1つ以上のI/Oコマンドを1つ以上のDBファイルシステムコマンドに変換するステップと、 DBファイルサーバ が、前記1つ以上のDBファイルシステムコマンドに応答して、1つ以上の 第1の データベースコマンドを、生成するとともに前記データベースを管理するデータベースサーバに対して発行するステップとを含み、 前記データベースサーバは、前記1つ以上の 第1の データベースコマンドを実行して前記データベースから 第1の データを検索し 、前 記 第1の データから生成され たファイルを第1の アプリケーションに提供 し、該以下のステップはさらに、 第2のアプリケーションに対してDBファイルAPIを提供するステップと、 前記DBファイルサーバが、前記DBファイルAPIを介して、前記第2のアプリケーションからの1つ以上の第2のDBファイルシステムコマンドを直接受取るステップとを含み、 前記1つ以上の第2のDBファイルシステムコマンドに応答して、1つ以上の第2のデータベースコマンドが、生成されるとともに前記データベースサーバに対して発行され、 前記データベースサーバは、前記1つ以上の第2のデータベースコマンドを実行して前記データベースから第2のデータを検索し、前記第2のデータから生成されたファイルを前記第2のアプリケーションに提供する、 コンピュータ読取可能媒体。
- 9前記ファイル を アプリケーションに提供 する処理 は、前記オペレーティングシステ ムにおける 1つ以上のルーチンによって 実行される 、請求項 8 に記載のコンピュータ読取可能媒体。
- 10前記DBファイルサーバが、 前記DBファイルAPIを介して、複数のファイルオペレーションを行なうためのコールを受取るステップ を含み、前記複数のファイルオペレーションは、少なくとも、前記データベースに記憶された第1のファイルに対する第1のファイルオペレーションと、前記データベースに記憶された第2のファイルに対する第2のファイルオペレーションとを含み、該以下のステップはさらに、 前記DBファイルサーバが、 前記複数のファイルオペレーションを、次のステップを行なうことによって、単一のトランザクションとして行なうステッ プを含 み、該次のステップは、 もし前記複数のファイルオペレーションのうちすべてのファイルオペレーションが失敗なく完了すれば、前記複数のファイルオペレーションによってなされたすべての変化を永久のものとするステップと、 もし前記複数のファイルオペレーションのうち何らかのファイルオペレーションが失敗すれば、前記複数のファイルオペレーションのすべてによってなされたすべての変化を無効にするステップとを含む、請求項 9 に記載のコンピュータ読取可能媒体。
- 11前記複数のファイルオペレーションは、 前記データベースに記憶された 単一のファイルに対する複数の書込オペレーションを含む、請求項 10 に記載のコンピュータ読取可能媒体。
- 12前記複数のファイルオペレーションを行なうステップは、 前記 データベースサーバに対して1つ以上 のデ ータベースステートメントを発行するステップを含み、前記データベースサーバは前記1つ以上のデータベースステートメントを実行して前記複数のファイルオペレーションを行なう、請求項 10 に記載のコンピュータ読取可能媒体。
- 13前記複数の書込オペレーションは、前記単一のファイルを前記データベースに記憶するためにネットワーク接続にわたって転送することに 相当 する、請求項 11 に記載のコンピュータ読取可能媒体。
- 14前記プロトコルサーバは、デバイスドライバインターフェイス として機能 する、請求項 8 ~ 13 のいずれか1項に記載のコンピュータ読取可能媒体。
Independent claims14
1 paragraph, as filed
[0001] [Refer to priority claim and related applications] This application is incorporated by reference in its entirety as if fully stated herein, entitled "Internet File System" by Eric Sedlar, August 5, 1999. Claim the domestic priority of the prior US provisional patent application serial number 60 / 147,538 of the Japanese application under 35 USC 119 (e). [0002] The present application is incorporated by citation as if the full text is fully stated herein, by Eric Sedlar, "Hierarchical Indexing for Accessing Hierarchical Information in Related Systems (Hierarchical Indexing). Related to US Patent Application Serial No. 09 / 251,757, filed February 18, 1999, entitled "Hierarchical Indexing for Accessing Hierarchically Organized Information in a Relational System"). [0003] This application is incorporated by reference in its entirety as if it were fully stated herein. Related to US Patent Application Sequential No. 09 / 571,496, filed May 15, 2000, entitled "File System that Supports Transactions" by Sedlar. [0004] This application is incorporated by reference in its entirety as if fully stated herein, entitled "Stored Query Directories" by Eric Sedlar, May 2000. Related to US Patent Application Serial No. 09 / 571,060 filed on May 15. [0005] This application is incorporated by reference in its entirety as if fully stated herein, by Eric Sedlar, "Event Notification System Tied to a File System." ) , Related to US Patent Application Serial No. 09 / 571,036, filed May 15, 2000. [0006] This application is incorporated by reference in its entirety as if fully stated herein, by Eric Sedlar, "Object File System with Typed Files". Related to US Patent Application Serial No. 09 / 571,492, filed May 15, 2000, entitled. [0007] This application is entitled "On-the-fly Format Conversion" by Eric Sedlar, the full text of which is incorporated by reference as if fully stated herein. Related to US Patent Application Serial No. 09 / 571,568 filed May 15, 2000. [0008] This application is incorporated by reference in its entirety as if fully stated herein, by Eric Sedlar and Michael J. et al. Related to US Patent Application Serial No. 09 / 571,696 filed May 15, 2000, entitled "Versioning in Internet File System" by Roberts. [0009] This application is entitled "Multi-Model Access to Data" by Eric Sedlar, the full text of which is incorporated by reference as if fully stated herein. Related to US Patent Application Serial No. 09 / 571,508 filed May 15, 2000. [0010] [Field of Invention] The present invention generally relates to an electronic file system, and specifically to a system that realizes an operating system file system using a database system. [0011] Background of the Invention Humans tend to categorize information, and the categories in which information is categorized are typically constructed in some hierarchical relationship with each other. For example, an individual animal belongs to a species, a species belongs to a genus, a genus belongs to a family, a family belongs to an eye, and an eye belongs to a class. [0012] With the advent of computer systems, electronic information storage technologies have been developed that greatly reflect the human desire for such a hierarchical organization. Traditional operating systems provide, for example, file systems that use hierarchy-based construction principles. Specifically, in a typical operating system file system (OS file system), directories are arranged hierarchically and documents are stored in those directories. Ideally, the hierarchical relationships between directories reflect some intuitive relationship between the meanings assigned to those directories. Similarly, if each document is stored in a directory, it would ideally be stored based on some intuitive relationship between the contents of that document and the meaning assigned to the directory in which the document is stored. is there. [0013] Figure 1 shows a typical mechanism used by software applications that create and use files (such as word processors) to store them in a hierarchical file system. With reference to Figure 1, operating system 104 exposes an application programming interface (API) to application 102. The API thus opened allows 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. Application 102 calls a file system routine via the OS file API to retrieve the data and store it on disk 108. The operating system 104 makes a call to the device driver 106 that controls access to disk 108 to retrieve files from disk 106 or store files on disk 106. [0014] OS file system routines provide a hierarchical structure of file systems. For example, an OS file system routine maintains information about hierarchical relationships between files and gives application 102 access to files based on their location within the hierarchy. [0015] Whereas electronic information is organized hierarchically, a relational database stores information in a table consisting of matrices. Each row is identified by its own RowID. Each column represents a record attribute and each row represents a particular record. Searching for data from a database is done by presenting a query to the database management system (DBMS) that manages the database. [0016] Figure 2 shows a typical mechanism used by a database application to access information in a database. With reference to FIG. 2, the database application 202 interacts with the database server 204 through the API provided by the database server 204 (database API). The API thus opened allows the database application 202 to access data using queries built in the database language supported by the database server 204. One of the languages supported by many database servers is the Structured Query Language (Structured Query Language). There is SQL). The database server 204 makes the database application 202 appear to have all the data stored in the rows of 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 a file in the OS file system. The operating system 104 makes a call to the device driver 106 to retrieve the file from disk 108 or store the file on disk 108. [0017] Each type of storage system has its advantages and limitations. Hierarchically constructed storage systems are simple, intuitive, and easy to implement, and are the standard model used by most application programs. Unfortunately, however, the simplicity of this hierarchical structure 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 with a particular filename created on a particular date. Hierarchical structure cannot facilitate the search process, as all directories must be searched. [0018] Relationship database systems are suitable for storing large amounts of information and for very flexible access to data. Even data that meets complex search criteria can be easily and efficiently searched from a relational database system for a hierarchically configured system. However, the process of formulating a query and presenting it to a database server is less intuitive than simply navigating through a directory hierarchy, and goes beyond the technical comfort of many computer users. [0019] At this time, application developers want to make the data created by those applications accessible through the hierarchical file system provided by the operating system, or through the more complex query interface provided by the database system. You will be asked to choose between what you want to be possible. In general, for applications that do not require the complex search capabilities of a database system, they are designed to store their data using the more general and simpler hierarchical file system provided by the operating system. While this simplifies both application design and application use, it imposes limitations on the flexibility and power of access to such data. [0020] On the other hand, when complex search capabilities are required, the application is designed to access the data using the query mechanism provided by the database system. In this case, the flexibility and power to access the data is increased, but at the same time, the complexity of the application is increased from the designer's point of view as well as the user's point of view. In addition, the existence of a database system is also required, which incurs additional costs for application users. [0021] [0021] In light of the above, it is clearly desirable for applications to be able to access data using a relatively simple OS file API. It is also desirable to be able to access the same data using a more powerful database API. [0022] [Summary of Invention] Technology is provided to access the data stored in the database. According to one technology, an application makes one or more calls to the operating system to access a file. The operating system includes routines that implement an operating system file system. The one or more calls are made to routines that implement the operating system file system. In response to the one or more calls, one or more database commands are issued to the database server that manages the database. The database server executes the database command to retrieve data from the database. A file is generated from the data and given to the application. [0023] The present invention will be described below with reference to the accompanying drawings for purposes of illustration and not limitation. In the figure, the same reference numerals represent the same elements. [0024] [Detailed Description of Preferred Examples] Methods and systems are provided that allow access to the same set of data through various interfaces, including database APIs and OS file system APIs. For purposes of illustration, a number of specific details will be given below to fully understand the invention, but those skilled in the art will appreciate the invention without those specific details. It will be clear to get. In other examples, well-known structures and devices are shown by block diagrams so as not to unnecessarily obscure the invention. [0025] Architectural overview FIG. 3 is a block diagram showing the architecture of the system 300 realized according to an embodiment of the present invention. Similar to the system shown in FIG. 2, the system 300 includes a database server 204 that provides a database API through which the database application 312 can access the data managed by the database server 204. Relationships where data managed by database server 204 can be queried using a database language supported by database server 204 (eg SQL) from the perspective of all entities accessing data managed by database server 204 through the database API. Stored in a table. Transparent to these entities, the database server 204 stores this data on disk 108. According to one embodiment, database server 204 implements disk management logic that allows data to be stored directly on disk to avoid the overhead associated with the OS file system of operating system 104. Therefore, the database server 204 either (1) calls the OS file system provided by the operating system 104 or (2) bypasses the operating system 104 by storing the data directly on disk. Data can be stored on disk. [0026] Unlike the system in Figure 2, system 300 provides translation engine 308, which translates I / O commands received from operating systems 304a and 304b into database commands issued by translation engine 308 to database server 204. To do. When the I / O command asks for data storage, the translation engine 308 issues the database command to the database server 204 so that the data is stored in the relational tables managed by the database server 204. When the I / O command asks for data retrieval, the translation engine 308 issues a database command to database server 204 to retrieve data from the relational tables managed by the database server. The translation engine 308 then feeds the retrieved data to the operating system issuing the I / O command. [0027] For operating systems 304a and 304b, the fact that the data transmitted to the translation engine 308 is finally stored in the relational table managed by the database server 204 is transparent. Since it is transparent to operating systems 304a and 304b, it is also transparent to applications 302a and 302b running on platforms that include those operating systems. [0028] For example, suppose a user of application 302a selects the "save file" option given by application 302a. Application 302a makes a call through the OS File API and causes 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, the translation engine 308 issues one or more database commands to the database server 204, causing the database server 204 to store the data contained in the file in the relationship table held by the database server 204. The database server 204 may store this data directly on disk, or may call operating system 104 to store the data in the OS file system provided by 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 disk 108. [0029] As another example, suppose a user of application 302a selects the "load file" option given by application 302a. Application 302a makes a call through the OS File API and causes 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 search the relationship table held by the database server 204 for data containing files to be searched. While retrieving the data, the database server 204 may search the data directory or call operating system 104 to retrieve the data from the OS files on disk 108. Once the data is retrieved, the desired file is "constructed" 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 application 302a through translation engine 308 and operating system 304a. [0030] System 300 incorporates a number of new features. The following sections describe these features in more detail. However, of course, specific examples are used to illustrate these features, and the invention is not limited to these specific examples. [0031] OS file system access to associated and stored data According to certain aspects of the invention, System 300 allows an application to access data stored in a database through a traditional OS file API. That is, allowing traditional applications designed to load files by calling the standard OS file API provided by the operating system to load files built on the fly from the data stored in the relationship table. become. Moreover, the fact that the data comes from the relation table is completely transparent to the application. [0032] For example, suppose database application 312 issues a database command to insert a row of data into a table in a database held by database server 204. Once the line is inserted, application 302a, which is designed only to access data using the relatively simple OS file API provided by operating system 304a, operates the command "Open File". Emit to system 304a. In response, the operating system 304a responds by issuing an I / O command to the translation engine 308, which in turn issues one or more database commands to the database server 204. The database server 204 causes the database server 204 to search for rows inserted by the database application 312 by executing database commands (typically in the form of database queries). A file of the file type predicted by application 302a is constructed from the data contained in that line, and the file thus constructed is returned to application 302a through the translation engine 308 and operating system 304a. [0033] System 300 not only allows applications that only support traditional OS file system access to load associated and stored data, but also information stored by applications that only support traditional OS file system access. In addition, database applications will be accessible using traditional query techniques. For example, suppose application 302a makes an OS call and saves the created file. The "save file" command is propagated 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 receives the data contained in that file from one or more of the data 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. [0034] Emulation of OS file system configuration in database As described above, calls to the file system routines of operating systems 304a and 304b are ultimately translated into database commands issued by translation engine 308 to database server 204. According to one embodiment of the present invention, the process of performing these conversions is simplified by emulating the characteristics of the file system realized by the operating systems 304a and 304b within the database server 204. [0035] For this configuration model, most operating systems implement a file system that composes files in a file hierarchy. Therefore, this OS file system call 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 to the corresponding database calls, a mechanism is provided to emulate the hierarchical file system within the relevant database system. One such mechanism was filed by Eric Sedlar on February 18, 1999, "HIERARCHICAL INDEXING for accessing hierarchically structured information in related systems. It is described in detail in US Patent Application No. 09 / 251,757 entitled "FOR ACCESSING HIERARCHICALLY ORGANIZED INFORMATION IN A RELATIONAL SYSREM)", the entire contents of which are incorporated herein by reference. [0036] Specifically, "HIERARCHICAL INDEXING" applications are hierarchically indexed by creating, retaining, and using them to efficiently access information in the relevant system based on pathnames. Techniques for emulating the configured system are described. Each item that has any child in the emulated hierarchical system has an index entry at its index. Index entries in the index are linked to each other in such a way as to reflect the hierarchical relationships within the items associated with these index entries. Specifically, if there is a parent-child relationship between the items associated with the two index entries, the index entry associated with the parent item has a direct link to the index entry associated with that child item. [0037] As a result, pathname resolution is performed by following a sequence of filenames in the pathname and following a direct link between the index entries associated with the item in that pathname. By using indexes in which 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 performed during that process is significantly reduced. [0038] Hierarchical index Hierarchical indexes that are consistent with the present invention support pathname-based access methods of hierarchical systems, moving from parent items to their children, as identified by pathnames. According to one embodiment, a hierarchical index conforming to the principles of the present invention employs an index entry containing the following three fields. RowID, FileID, and Dir_entry_list (stored as an array). [0039] Figure 5 shows a tiered index 510 that can be used to emulate a tiered storage system in a database. FIG. 6 shows a particular file hierarchy that the hierarchy index 510 emulates. FIG. 7 shows the file table 710 used to store the files shown in FIG. 6 in the relational database. [0040] Hierarchical index 510 is a table. The RowID field contains an ID generated by the system and 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. [0041] According to one embodiment of the invention, the hierarchical index 510 stores only index entries for items that have children. Therefore, in terms of an emulated hierarchical file system, the only items that have an index entry at hierarchical index 510 are directories that are parent to other directories and / or directories that currently store documents. Those items that have no children (eg, Example.doc, Access, Appl, App2, App3 in Figure 6) are preferably not included. The Dir_entry_list field of an index entry for a given file stores an "array entry" for each of the child files of a given file in an array. [0042] For example, index entry 512 is for Windows (R) directory 614. Word directory 616 and Access directory 620 are children of Windows (R) directory 614. Thus, the Dir_entry_list field of index entry 512 for Windows (R) directory 614 contains an array entry for Word directory 616 and an array entry for Access directory 620. [0043] According to one embodiment, the particular information that the Dir_entry_list field stores for each child includes the child's filename and the child's FileID. For children that have their own entries in the hierarchical index 510, the Dir_entry_list field also stores the RowID of the child index entry. For example, Word directory 616 has its own entry at hierarchical index 510 (entry 514). Therefore, the Dir_entry_list field of index entry 512 contains the name of directory 616 (Word), the RowID of the index entry for directory 616 in the hierarchical index 510 (Y3), and the FileID of directory 616 (X3). As described in more detail, the information contained in the Dir_entry_list field makes it faster and easier to access information based on pathnames. [0044] Some of the main principles of hierarchical indexes are: -Dir_entry_list information for index entries for a given directory is kept together as as few disk blocks as possible. This is because the most frequently used file system operations (pathname derivation, directory listing) will have to look at a large number of entries in a directory whenever it is referenced. Is. In other words, a directory entry should have a high degree of locality to the reference, as other entries in the same directory are often referenced when a particular directory entry is referenced. [0045] 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. If you group directory entries together into an array of means that does not need to iterate over the keys that identify the directories they contain, all the entries in the directory will share the same key. [0046] The time it takes to derive the pathname should be proportional to the number of directories in the path, not the total number of files in the file system. This allows users to keep frequently accessed files near the top of the file system tree, which has less access time. [0047] All of these elements are present in a typical file system directory structure, such as UNIX (R) systems for inodes and directories. By using hierarchical indexes such as those described here, their purpose matches the structure that the relevant database can understand and query, and the database server is separate from the one used to derive the pathname. It becomes possible to perform an ad hoc search of a file in the above manner. To do this, one must use the database concept of an index. That is, subordinate information (file data in this case) placed in a separate data structure in another way designed to optimize access through one particular method (in this case, deriving pathnames in a hierarchical tree). It is a duplicate of the part of. [0048] Use of hierarchical indexes How the hierarchical index 510 can be used to access a file based on the pathname of the file will be described here with reference to the flowchart of FIG. For illustration purposes, assume that document 618 is accessed through its pathname. The path name of this file is /Windows(R)/Word/Example.doc, which will be referred to as the "input path name" below. Given this pathname, the pathname derivation process begins by locating the index entry for the first name in this input pathname at the hierarchical index 510. For some file systems, the first name in the pathname is the root directory. Therefore, the pathname derivation process for locating files in the emulated file system begins by locating index entry 508 in root directory 610 (step 800). Since all pathname derivation operations begin by accessing the root directory index entry 508, the data indicating the location of the index entry for root directory 610 (index entry 508) is the root directory index entry at the beginning of any search. It can be held in a convenient location outside the hierarchical index 510 to quickly locate the 508. [0049] Once the location of index entry 508 for root directory 610 is located, the DBMS determines if there is still any filename in the input pathname (step 802). If there are no more files in the input pathname, control proceeds to step 820, using the FileID stored in index entry 508 to look for the root directory entry in file table 710. [0050] 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 following filename (for example, "Windows (R)" is selected from the input pathname. In step 806, the DBMS looks at the Dir_entry_list field of index entry 508 and the location of the array entry for the selected filename To find out. [0051] In this example, the file name following the root directory in the input path name is "Windows (R)". Therefore, step 806 involves searching the Dir_entry_list for index entry 508 for the array entry with file name "Windows (R)". If 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, index entry 508 Dir_entry_list contains a "Windows (R)" array entry. Therefore, control shifts from step 808 to step 822. [0052] The information in Dir_entry_list at 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 about this child: That is, this is an index entry that matches RowIDY2, and this FileID is X2. [0053] In step 822, it is determined whether the input pathname still has some file name. If there is no file name anymore, control moves from step 822 to step 820. In this example, "Windows (R)" is not the last file name, so control shifts to step 824 instead. [0054] Since "Windows (R)" is not the last file name in the input path, the FileID information contained in Dir_entry_list is not used during this path derivation operation. Rather, Windows (R) directory 614 is only part of the identified path, not the target, so File Table 710 cannot be examined at this point. Instead, in step 824, the RowID (Y2) for "Windows (R)" found in the Dir_entry_list of index entry 508 is used to locate the index entry for Windows (R) directory 614 (index entry). 512). [0055] Examining the Dir_entry_list at index entry 512, the system looks for the next file name in the input pathname (steps 804 and 806). In this example, the file name "Word" follows the file name "Windows (R)" in the input path. Therefore, the system searches the Dir_entry_list for index entry 512 for the "Word" array entry. Such an entry exists in the Dir_entry_list of index entry 512, indicating that "Windows (R)" actually has a child named "Word" (step 808). At step 822, it is determined that the file name is still in the input path, so control proceeds to step 824. [0056] When it finds an array entry for "Word", the system reads the information in that array entry and finds an index entry for Word directory 616 in RowIDY3 in hierarchical index 510, and certain information that belongs to Word directory 616. Is found in row X3 in file table 710. File table 710 cannot be examined because word directory 616 is simply part of the identified path, not the target. Instead, the system uses RowID (Y3) to locate index entry 514 for Word directory 616 (step 824). [0057] At RowIDY3 at hierarchical index 510, the system finds index entry 514. In step 804, the next file name "Example.doc" is selected from the input path name. In step 806, the Dir_entry_list of index entry 514 is searched to find an array entry for "Example.doc" (step 808), which indicates that "Example.doc" is a child of Word directory 616. .. The system also finds that Example.doc has no indexing information at hierarchical index 510 and that specific information about Example.doc can be found in File Table 710 using FileIDX4. .. Since Example.doc is the target file to be accessed (ie the last filename in the input path), control moves to step 820, where the system uses FileIDX4 to access the appropriate line in file table 710. , And extract the file body (BLOB) stored in the body column of that line. In this way, the Example.doc file is accessed. [0058] [0058] Only hierarchical index 510 was used to access this file. No table scan was needed. If the block size and filename length are typical, then at least 600 directory entries will fit into one disk block, and a typical directory will have less than 600 entries. That is, the list of directory entries in a given directory will typically fit into a single block. In other words, each index entry in the hierarchical index 510, including the entire Dir_entry_list array of index entries, will typically fit into a single block and can therefore be read in a single I / O operation. [0059] In moving from index entry to index entry in hierarchical index 510, it is possible that some disk access may be required if the different index entries in the index are in different 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 that 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. [0060] The above description of 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. In addition, some protocols may not even possess hierarchical features. As such, the invention is not limited to any particular technique for emulating the hierarchical features of some protocols. Moreover, the invention is not limited to protocols that are hierarchical in nature. [0061] Emulate other OS file system features in the database Beyond the hierarchical structure of OS filesystems, another feature of most OS filesystems is that they hold specific system information about the files they store. According to one embodiment, this OS file system feature is also emulated within the database system. Specifically, the translation engine 308 issues a command to store the "system" data of a file on a row in a file table (eg, file table 710) managed by the database server 204. According to one embodiment, all or most of the file contents are stored as large binary objects (BLOBs) in a column with that line. In addition to this BLOB field, this file table also contains a field for storing attribute values that correspond to what is implemented in the OS file system. Such attribute values include, for example, the owner or creator of the file, the date the file was created, the last modified data of the file, the hard link to the file, the filename, the file size, and the file type. [0062] When the translation engine 308 issues database commands to the database server 204 to perform some file operation, those database commands include statements that cause the attributes associated with the file associated with that operation to change appropriately. For example, in response to inserting a new row in the file table for a newly created file, the translation engine 308 issues a database command to (1) tell the user who is creating the file. Store the value in the "Owner" column of the row, (2) store the value indicating the current date in the "Created Date" column of the row, and (3) store the value indicating the current date and time in the "Last" column. Store in the "Change" column, and (4) store the value indicating the size of the BLOB in the "Size" column. In response to subsequent operations in this file, the values in these fields will change as required by these operations. For example, when translation engine 308 issues a database command that modifies the contents of a file stored on a particular line, translation engine 308 updates the "last modified" value for that particular line as part of the same operation. Issue a database command to In addition, if this change changes the file size, the translation engine 308 also issues a database command that updates the "size" value for that particular row. [0063] Another feature of most OS file systems is the ability to provide security for each file. For example, some versions of Windows (R) NT, VMS, and UNIX (R) have access control lists that show the rights that different entities have with respect to each file. According to an embodiment of the invention, this OS file system feature is emulated in a database system by holding a "security table", where each row of this security table is similar to an entry with an access control list. Includes content. For example, one column in this security table for storing values that identify a file, and another column for storing values that represent permission types (for example, read, update, insert, execute, modify permissions). And another field to store a flag indicating whether or not the permission was granted, and an owner field to store a value representing 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, use one or more additional tables to map the group ID to the user IDs of the members of the group. [0064] Before issuing a database command to access a file stored in a file table managed by database server 204, the translation engine 308 requested access to the identified file by the user requesting access. Issue a database command that verifies that you have permission to execute the type of. Such a pre-access database command retrieves data from the security table and determines whether the user requesting access is allowed to perform that access. If the data retrieved in this way indicates that the user does not have the requested permissions, the translation engine 308 will not issue a command to perform the requested operation. Instead, the 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 an application requesting access if the application attempts to access a file held in that operating system's OS file system without permission. Send the same OS error message as the one. Thus, even under error conditions, the fact that the data is stored in the relational database rather than in the OS file system is transparent to the application. [0065] 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 held by a database system that implements the techniques described herein may vary from implementation to implementation. For example, database 204 can store all of the system data supported by the OS file system of operating system 304a, but can only store some system data supported by the OS file system of operating system 304b. Alternatively, the database server may store all of the system data supported by both operating systems 304a and 304b, or some of the system data supported by either one of operating systems 304a and 304b. May be stored. [0066] As shown in Figure 3, database server 204 stores files originating from a number of separate OS file systems. For example, operating system 304a may be different from operating system 304b, and both operating systems 304a and 304b may be different from operating system 104. OS file systems 304a and 304b can have contrasting features. For example, the OS file system 304a can allow the file name to contain the character "/", whereas the OS file system 304b cannot. According to one embodiment, in such a situation, the 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 its filename, the translation engine 308 issues a database command that causes database server 204 to perform that operation. On the other hand, when application 302b attempts to store a file that contains the character "/" in its filename, the translation engine 308 raises an error. [0067] Alternatively, the translation engine 308 may be configured to implement a single set of rules for all operating systems. For example, if the file name is invalid even in one operating system supported by the translation engine 308, the translation engine 308 will issue a command that identifies the file name. It is possible to implement a rule that even if it is valid, it will cause an error. [0068] Converting OS file system calls to database queries By building a mechanism for emulating OS file system features within a database system, OS file system calls can be transformed without losing the functionality expected by the application making the OS file system call. It can be translated into a database query by the ration engine 308. This OS file system call made by those applications is made through the OS file API provided by the operating system in which they are running. For example, for programs written in the "C" programming language, a source code file entitled "stdio.h" is used to identify the interface of an operating system's OS file API. Since this stdio.h file is included in the applications, these applications will know how to call the routines that implement the OS file API. [0069] The specific routines that implement the OS File API can vary from operating system to operating system, but typically include routines for performing the following operations: Open a file, read from a file, write to a file, seek inside a file, lock a file, and close a 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 = update Read from file = select Lock file = Lock the line associated with the file Seek into file = update counter Close file = complete transaction (Windows (R) OS file system protocol requires directory entry to be completed just before file data is written, no other protocol.) Some filesystems expect the name of a file to be visible even before receiving the contents of the file, as described in more detail below. 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. [0070] According to one embodiment, a counter is used to track the "current location" in the file. In an embodiment where the file is stored as a BLOB, the counter can take the form of an offset from the beginning of the BLOB. When the "Open File" command is executed, a counter is created and set to a value that indicates 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. The seek operation causes the counter to update to point to the location in the blob indicated by this seek operation parameter. According to one embodiment, these operations are described in US Patent Application No. 08 / 962,482, filed October 31, 1997 by Nori et al., entitled "LOB LOCATORS". This is facilitated by the use of such LOB locators, the entire contents of this application being incorporated herein by reference. [0071] On some operating systems, OS locks may persist when you close a file. To emulate this feature, lock file commands are translated into session lock requests. As a result, if "Complete Transaction" is executed in response to a command to close this file, the lock on the line associated with that file is not automatically released. The lock thus established is released either explicitly in response to the command to unlock the file or automatically in response to the termination of the database session for which the lock was obtained. [0072] Ongoing I / O operations When a file is created, the directory in which it is created is updated to indicate the existence of the file. On some OS file systems, changing directories to indicate new files is accomplished before the new files are fully generated. Some applications designed for those OS file systems take advantage of that feature. For example, an application could open a new file with the first file handle and proceed to write data into that file. The same application can open the file with a second file handle while the data is being written. [0073] Emulating this feature in a database entails special problems. This is because, in general, another transaction cannot see the changes made by that transaction until the database transaction is completed. For example, suppose the first database transaction is started in response to the first "open" command. The first transaction updates the directory table to indicate that the file exists in a particular directory, and then updates the file table to insert a line 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 contains changes to the directory table and new rows in the file table. Not visible until the first transaction is completed. [0074] According to one embodiment of the invention, the ability to see a directory entry for a file in progress updates the directory table as a separate transaction from the transaction used to insert lines for that file into the file table. By doing so, it is emulated in the database system. Thus, in response to the first open command, the translation engine 308 issues a database command, (1) initiating the first transaction, and (2) displaying the directory table to indicate the existence of a new file. Modify, (3) complete the first transaction, (4) start the second transaction, (5) insert a row in this file into the file table, (6) complete the second transaction Let me. By completing changes to the directory table separately from changes to the file table, a third transaction initiated in response to the second open command is a directory while the insert into the file table is still in progress. You can see the entries in the table. If the second transaction fails, this directory will be left with no contents and with the file entry. [0075] Translation engine According to one embodiment of the present invention, the translation engine 308 is designed with two layers. These layers are shown in Figure 4. With reference to FIG. 4, the translation engine 308 includes a protocol server layer and a DB file server layer 408. The DB file server 408 allows the application to access the data stored in the database managed by the database server 204 through an alternative API (referred to here as the DB file API). The DB 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 the traditional OS File API. [0076] However, unlike the OS file API, the DB file API incorporates the concept of a transactional database API. That is, the DB file API allows an application to identify that a set of file operations is performed atomically. The advantages of having a file system in which the transaction took place are described in more detail below. [0077] DB file server The DB file server 408 is responsible for converting DB file API commands into database commands. 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). [0078] According to one embodiment, the DB file server 408 is object oriented. Thus, the routine supplied by the DB file server 408 is called by instantiating an object and by calling the method associated with that object. In one implementation, DB File Server 408 specifies a "transaction" object class that includes: Insert, save, update, delete, complete and rollback. The DB File API provides an interface that allows external entities to instantiate and use this transactional object class. [0079] Specifically, when an external entity (for example, application 410 or protocol server) makes a call to DB file server 408 and creates an instance of a transaction object, DB file server 408 issues a database command that causes database server 204 to start a new transaction. send. This external entity then calls the method of the transaction object. Calling a method results in a call to DB file server 408. The DB file server 408 responds to this call by issuing a database command corresponding to the database server 204. All database operations performed in response to a method call on a given transaction object are performed as part of the database transaction associated with this given transaction object. [0080] [0080] Importantly, the method called for a single transaction object can involve multiple file operations. For example, application 410 can interact with DB file server 408 as follows: Application 410 instantiates the transaction object TXO1 by calling it through the DB file API. In response, DB File Server 408 issues a database command within Database Server 204 to initiate transaction TX1. Application 410 calls the TXO1 update method to update the file F1 stored in the database managed by 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. Application 410 calls the TXO1 update method to update the second file F2 stored in the database managed by 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. Application 410 then calls the TXO1 completion method. In response, the DB file server 408 issues a database command to the database server 204 to complete TX1. If the update to file F2 fails, the TXO1 rollback method is called to roll back all changes made by TX1, including the update to file F1. [0081] Here, the technology has been described with reference to a DB file server that uses transaction objects, but other implementation examples are also possible. For example, within a DB file server, objects can be used to represent files rather than transactions. In such an embodiment, a file operation can be performed by invoking the method of the file object and by passing data to it that identifies the transaction in which the operation is about to be performed. Therefore, the present invention is not limited to a DB file server that implements any particular set of object classes. [0082] For purposes of explanation, the example shown in FIG. 4 shows a DB file server 408 as a process execution external database server 204 that communicates with the database server 204 through the database API. However, according to an alternative embodiment, the functionality of the DB file server 408 is built into the database server 204. By incorporating the DB file server 408 into the database server 204, the amount of interprocess communication generated while using the DB file system is reduced. The database server created by incorporating the DB file server 408 into the database server 204 therefore has two alternative APIs for accessing the data managed by the database server 204: the DB file API and the database API (SQL). )I will provide a. [0083] Protocol server The protocol server layer of the translation engine 308 is responsible for translating between specific protocols and DB file API commands. For example, protocol server 406a translates I / O commands received from operating system 304a into DB file API commands it sends to DB file server 408. Protocol server 406a also translates DB file API commands received from DB file server 408 into I / O commands it sends to operating system 304a. [0084] 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). In addition, overlaps often occur between sets of protocols supported by different operating systems. However, for illustrative purposes, a simplified environment is shown in which operating system 304a supports one protocol and operating system 304b supports another. [0085] I / O API As mentioned above, a protocol server is used to convert I / O commands into DB file commands. The interface between the protocol server and the OS file system with which they communicate is a comprehensively labeled I / O API. However, the particular I / O API given by a protocol server depends on both (1) the entity with which the protocol server communicates and (2) how the protocol server is made to appear in that entity. For example, the operating system 304a may be Microsoft Windows (R) NT, and the protocol server 406a may be designed to appear as a device driver for Microsoft Windows (R) NT. Under this circumstance, the I / O API presented to operating system 304a by protocol server 406a 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 it communicates with any storage device. The fact that the files stored on protocol server 406a and the files retrieved from them are actually stored in and retrieved from the database held by database server 204 is entirely in Windows (R) NT. It is transparent. [0086] While some protocol servers used by the translation engine 308 may present device driver interfaces to their respective operating systems, other protocol servers may appear as other types of entities. For example, operating system 304a may be the Microsoft Windows (R) NT operating system, where protocol server 406a presents itself as a device driver, while operating system 304b is the Microsoft Windows (R) 95 operating system. The protocol server 406b may also present itself as a System Message Block (SMB) server. In the latter case, the protocol server 406b will typically be running on a different machine than the operating system 304b, and communication between the operating system 304b and the protocol server 406b will occur over a network connection. It will be. [0087] In the above example, the source of the I / O command handled by the protocol server is the OS file system. However, the translation engine 308 is not limited to being used with OS file system commands. Rather, a protocol server may be provided to perform the conversion between the DB file command and some type of I / O protocol. In addition to the I / O protocol used by the OS file system, other protocols that a protocol server can provide for it include, for example, the File Transfer Protocol (FTP) and the email system (POP3 or IMAP4). ) Includes the protocol used by. [0088] Just as the interface provided by the protocol server working with the OS file system is directed by a special OS, the interface provided by the protocol server working with the non-OS file system is to the entity that will issue the I / O command. It will change based on. For example, a protocol server configured to receive I / O commands according to the FTP protocol will provide the FTP server API. Similarly, a protocol server configured to receive I / O commands according to the HTTP, POP3, and IMAP4 protocols will provide the HTTP server, POP3 server, and IMAP4 server APIs, respectively. [0089] Like the OS file system, each of the non-OS file protocols predicts the specific attributes that will be retained for that file. For example, most OS file systems store data that indicates the date of last modification of a file, whereas email systems, for each email message, indicate whether the email message was read or not. To store. A protocol server for each of a particular protocol implements the logic required to ensure that the semantics of that protocol are emulated in the database file system. [0090] Transactionally processed file system Within a database system, operations are typically performed as part of a transaction. The database system performs all operations that are part of a transaction as a single atomic operation. That is, either all of the operations are completed successfully, or none of the operations are performed. During the execution of a transaction, if an operation cannot be performed, all previously performed operations of the transaction are canceled or "rolled back". [0091] 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 an incomplete file operation can lead to directory structure and file corruption. [0092] According to one aspect of the invention, a transaction processed file system is provided. As mentioned above, the translation engine 308 converts the I / O command into a database statement sent to the database server 204. The set of statements sent by the 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 the 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 point of failure. [0093] The circumstances that cause a transaction to fail can change based on the system from which the I / O command originated. For example, the OS file system can support the concept of signatures, and a digital "signature" that identifies the source of the file here is attached to the file. A transaction initiated to store a signed file can fail, for example, if the stored file is not signed as expected. [0094] On-the-fly intelligent file conversion According to one embodiment of the invention, the files are processed before being inserted into the relational database and reprocessed when they are retrieved from the 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. [0095] With reference to FIG. 9, the translation engine 308 includes a rendering unit 904 and a Pershing unit 902. In general, the pershing unit 902 is responsible for inbound processing of the file, and the rendering unit 904 is responsible for outbound processing of the file. Each of these functional units will be described in more detail here. [0096] Inbound file processing The inbound file is passed to the DB file server 408 via the DB file API. Upon receiving the inbound file, the pershing unit 902 identifies the file type for that file and then parses the file based on that file type. During the pershing process, the pershing unit 902 extracts structured information from the pershed file. This structured information may include, for example, information about the file being parsed, or data representing logically distinct components or fields of the file. This structured information is stored in the database along with the file from which the structured information originated. After that, a query is issued to the database server, and a file can be selected and searched based on whether or not the structured information extracted in this way satisfies a specific search condition. [0097] The particular technique used by the Pershing Unit 902 to perform the parsing of a document, and the structured data it produces, will vary based on the type of document passed to the Pershing Unit 902. Therefore, before performing any pershing operation, the pershing unit 902 identifies the file type of this document. Various factors can be considered in determining the file type of a file. For example, in DOS or Windows (R) operating systems, the file type of a file is often indicated by the extension in the file's filename. That is, if the file name ends with ".txt", the parser unit 902 classifies the file as a text file and gives the file a text file-specific parsing technique. Similarly, if the filename ends with ".doc", parser unit 902 classifies the file as a Microsoft Word document and gives the file Microsoft Word-specific parsing techniques. The Macintosh Operating System, on the other hand, stores file type information for a file as an attribute that is kept separate from that file. [0098] Another factor that the Pershing Unit 902 can consider in determining the file type of a file is, for example, the directory in which the file is located. Therefore, parser unit 902 may be configured to classify and parse all files stored as WordPerfect documents in the \ WordPerfect \ document directory, regardless of the filenames of those files. [0099] Alternatively, both the file type of the inbound file and the file type requested by the requesting entity may be identified by or estimated through the information provided to DB File Server 408. is there. For example, when a web browser sends a message, the message typically contains information about that browser (eg, browser type, version, etc.). When a web browser requests a file through an HTTP protocol server, this information is communicated to the DB file server 408. Based on this information, the rendering unit 904 can also look up information about the capabilities of its browser and estimate the best file type from those capabilities and bring it to the browser. [0100] As mentioned above, the particular pershing technique used by the Pershing 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 the Pershing Unit 902 may include embedded metadata, derived 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 analyzing the file. System metadata is data about a file provided by the system from which the file originated. [0101] For example, application 410 passes a Microsoft Word document to the pershing unit 902. Pershing unit 902 parses the document and extracts information about the files embedded within the file. Information embedded in a Microsoft Word document includes, for example, data indicating the author of the document, the category to which the document is assigned, and comments about the document. [0102] In addition to locating and extracting embedded information about a Word document, Parser 902 can also derive information about that document. For example, parser 902 may scan this Word document to determine the number of pages, paragraphs, and words contained in this document. Finally, the system from which this document originated may provide the pershing unit 902 with data indicating the size, creation date, last modification date, and file type of this document. [0103] The more structured the file type of a document, the easier it is to extract certain items of structured data from this document. For example, an HTML document typically has a delimiter or "tag" that identifies the beginning and end of a particular field (title, heading 1, heading 2, etc.). These delimiters are used by the Pershing Unit 902 and can result in metadata items for some or all of the delimited fields by parsing an HTML document. Similarly, the XML file is highly structured and the XML parser will be able to extract another item of metadata for some or all of the fields contained in the XML document. [0104] Once the parsing unit 902 is generating structured data for a file, the DB file server 408 issues a database command to the database server 204 and inserts the file into a line in the file table (eg file table 710). Let me. According to one embodiment, a database command issued in this way stores this file as a BLOB in one column of the line and stores various items of structured data generated for that file in the other column of the same line. Store in. [0105] Alternatively, some or all of the structured data items for a file can be stored outside the file table. Under these circumstances, the line that stores the structured data associated with a file will typically contain data that identifies that file. For example, suppose a Word document is stored in row R20 of the file table, and system metadata for that Word document (for example, creation date, modification date, etc.) is stored in row R34 of the system attributes table. In such a situation, both R20 in the file table and R34 in the system attribute table will typically include a FileID field that stores a unique identifier for the Word document. The query then retrieves both the file and the system metadata for that file by issuing a join statement that joins the rows in the file table and the rows in the system attributes table based on the FileID value. Can be done. The technique for storing the file attributes in the table associated with the file "class" will be described in more detail below. [0106] Outbound file processing The outbound file is constructed by the rendering unit 904 based on the information retrieved in response to the database command sent to the database server 204. Once built, the outbound file is transported to the entity that requested it through the DB File API. [0107] Importantly, the file type of the outbound file generated by rendering unit 904 (target file type) is not necessarily the same file type (source file type) as the file that produced the data used to build that outbound file. It does not have to be. For example, the rendering unit 904 may build a text file based on the data originally stored as a Word file in the database. [0108] In addition, the entity requesting the outbound file may be on a completely different platform using a completely different protocol than the entity that gave rise to the file from which the outbound file was built. For example, suppose protocol server 406b implements an IMAP4 server interface and protocol server 406a implements an HTTP server interface. Under these circumstances, email documents originating from the email application can 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, the parsing unit 902 calls the parsing technique associated with this email file type (eg RFC822), and the rendering unit calls the rendering routine that builds the HTML document from the email data retrieved from the database. Let's do it. [0109] Parser and renderer registration 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 enormous. Therefore, it is impractical to build a parsing unit 902 that handles all known file types, or a rendering unit 904 that handles all possible conversions from file type to file type. [0110] According to one embodiment of the invention, the problem caused by the proliferation of file types can be by making the type-specific pershing module registerable in the pershing unit 902 and also by making the type-specific rendering module registerable in the rendering unit 904. Will be dealt with. A type-specific pershing module is a module that implements pershing technology for a particular file type. For example, a Word document is parsed using the Word document parsing module, while a POP3 email document is parsed using the POP3 email parsing module. [0111] Like the type-specific parsing module, a type-specific rendering module is a module that implements the technology for converting data associated with one or more source file types to one or more target file types. .. For example, a type-specific rendering module can be provided to convert a Word document into a text document. [0112] Even if the source file type and the target file type are the same, conversion may be required. For example, when parsed and inserted into a database, the contents of an XML document are not held in a single blob, but can spread across many columns in many tables. In that case, XML is the source file type for the data, even if the data is no longer stored as an XML file. Type-specific rendering modules can be provided to build XML documents from that data. [0113] When the pershing unit 902 receives an inbound file, the pershing 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 pershing module is registered for that file type, the pershing unit 902 calls the pershing routine given by that type-specific pershing module. These pershing routines parse inbound files to generate metadata, which is then stored with the file in the database. If no type-specific pershing module is registered for the file type, the pershing unit 902 may either generate an error or apply general purpose pershing techniques to the file. This general purpose pershing technique has no knowledge of the contents of the file, which limits the general purpose pershing technique with respect to the useful metadata that can be generated for the file. [0114] When the rendering unit 904 receives a file request, the rendering unit 904 issues a database command to retrieve the data associated with that file. That data contains metadata that indicates the source file type of the file. The rendering unit 904 then determines if 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, it will call the rendering routine given by that type-specific rendering module to build the file, and request the file thus built. Give to the entity that is doing. [0115] Various factors can be used to determine which target file type should be selected by the type-specific rendering module. The entity requesting the file may explicitly indicate the type of file it requests. For example, a text editor can only work with text files. Text editors can request files whose source file type is Word document. In response to this request, a Word-specific rendering module is called, which converts this Word document into a text file based on the requested target file type. This text file is then taken to the text editor. [0116] In other cases, the entity requesting the file may support many 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, and (2) is the best in that set. Incorporate the logic of choosing a target file type. This selection of the best target file can take into account a variety of factors, including the file-specific characteristics of the problem. [0117] For example, (1) DB File Server 408 receives a request for a file, (2) the source file type of that file indicates that the file is a "BMP" image, and (3) this request is "GIF", " Assume that it is initiated by an entity that supports "TIF" and "JPG" images, and (4) the BMP source type specific rendering module supports the "GIF", "JPG" and "PCX" target file types. .. Under these circumstances, the BMP source type-specific rendering module determines that both "GIF" and "JPG" are potential target file types. To choose from these two possible target file types, the BMP source type-specific rendering module can 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 can proceed to convert this BMP file to a JPG file. The resulting JPG file is then delivered to the requesting entity. [0118] According to one embodiment, type-specific pershing and rendering modules are registered by storing information indicating the module's capabilities in a database table. For example, an entry for a type-specific rendering module may indicate that it should be used when the source file type is XML and the requesting entity is a Windows (R) based web browser. An entry for a type-specific pershing module can indicate that the source file type should be used if it is a .GIF image. [0119] 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 that issued the command. The DB 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 current use. For inbound files, the appropriate parsing module is called to parse the file before it is inserted into the database. For outbound files, the appropriate rendering module is called to build the outbound file from the data retrieved from the database. [0120] According to one embodiment of the invention, a DB file system allows file classes to be defined using object-oriented technology, where each file type belongs to one file class and the other file classes. Attribute from the file class of can be inherited. 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 described in more detail below. [0121] Stored query directory As described above, a hierarchical directory structure can be implemented in a database system using a file table 710, where each line corresponds to a file. Hierarchical index 510 may be employed to efficiently locate the lines associated with the identified file based on the pathname of the file. [0122] In the examples shown in FIGS. 5 and 7, the child files in each directory are explicitly listed. In particular, the child files for each directory are listed in the index entry Dir_entry_list associated with that directory. For example, index entry 512 corresponds to Windows (R) directory 614, and Dir_entry_list in index entry 512 explicitly lists "Word" and "Access" as child files in Windows (R) directory 614. [0123] One aspect of the invention provides a file system in which child files in some or all directories are dynamically determined based on the search results of a stored query rather than being explicitly listed. File. Such a directory is referred to here as a stored query directory. [0124] For example, a file system user wants to group all files with the .doc extension into a single directory. In a traditional file system, the user creates a directory, searches for all files with the .doc extension, and then moves the files found in this search to the newly created directory, or with the newly created directory. Either create a hard link with the file found in the search. Unfortunately, the contents of this newly created directory only accurately reflect the state of the system at the time the search was performed. Even if you change the name to one that does not have a .doc extension, the field will remain in the directory. In addition, files with the .doc extension created in other directories after the new directory is established will not be included in this new directory. [0125] Rather than statistically defining the membership of the new directory, the membership of this directory can be specified by stored queries. A stored query that selects a file with the .doc extension can appear as follows: [0126] Q1: Q1: SELECT<sup>*</sup> from files_table However, files_table.Extension = doc Seen in Figure 7, when executed against table 710, query Q1 selects rows R4 and R12, which are the rows for the two documents entitled "Example.doc". [0127] According to one embodiment of the present invention, a mechanism for linking a query such as query Q1 to a directory entry in the hierarchical index 510 is provided. If a directory entry containing such a link is encountered while traversing the hierarchical index 510, the query identified by this link will be executed. Each file selected by this query is treated as a child of the directory associated with the directory entry, just as if it were an explicit entry in the database table that stores the directory entry. [0128] For example, suppose a user wants to create a directory "Documents" that is a child of Word616, and this document directory contains all files with the extension .doc. According to one embodiment of the invention, this user designs a query that identifies selection criteria for files that will belong to this directory. In this example, the user can generate query Q1. This query is then stored in the database system. [0129] Like other types of directories, a line for the Document directory is added to 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. Rather than explicitly listing the children in Dir_Entry_list, the new directory entry for this Document directory contains a link to the stored query. [0130] Figures 10 and 11 show the state of the hierarchical index 510 and the file table 710 after the appropriate entries have been made for the Documents directory, respectively. As shown in Figure 10, index entry 1004 has been created for the Documents directory. The Dir_entry_list field in index entry 1004 is null because the children of the Documents directory are dynamically determined based on the result set of the stored query. Instead of statically enumerating the child files, index entry 1004 contains a link to the stored query 1002 that is to be executed to determine the child files in the Documents directory. [0131] In addition to creating index entry 1004 for the Documents directory, the existing index entry 514 for the Word directory is updated to indicate that Documents is a child of the Word directory. Specifically, a Dir_entry_list array entry is added to index entry 514 to identify the name "Documents", the RowID of the index entry for the Documents directory (ie Y7), and the FileID of the Documents directory (ie X13). [0132] In the illustrated embodiment, two columns are added to the hierarchical index 510. Specifically, the Stored Query Directory (SQD) field contains a flag that indicates whether the directory entry is for a stored query directory. In the directory entry for the stored query directory, the query pointer (QP: Query) In the Pointer) field, the link to the stored query associated with the directory is stored. The QP field is null for directory entries for directories other than the stored query directory. [0133] The nature of the link can vary from implementation to case. 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 can simply be a unique stored query identifier that can be used to look up a stored query in a stored query table. The present invention is not limited to any particular type of link. [0134] With reference to FIG. 11, here is illustrated a file table 710 that has been updated to include a line (R13) for the Documents directory. According to one embodiment, the same metadata held for the traditional directory is also kept for the Documents directory. For example, line R13 may include creation date, last modified date, and so on. [0135] FIG. 12 is a block diagram of a file hierarchical structure. The hierarchical structure shown in Figure 12 is the same as that shown in Figure 6, with the addition of the Documents directory 1202. When any application requests to view the contents of Documents directory 1202, the database executes the query associated with that Documents directory 1202. The query selects files that satisfy this query. The result of this query is then presented to the application as the contents of the Documents directory 1202. At the time shown in Figure 12, the file system contains only two files that satisfy the query associated with Documents directory 1202. Both of these files are entitled Example.doc. Therefore, these two Example.doc files 618 and 622 are shown as children of the Documents directory 1202. [0136] In many OS file systems, the same directory cannot store two different files with the same name. Therefore, the presence of two files in the Documents directory 1202, entitled Example.doc, can break the rules of the OS file system. Various techniques can be used to address this issue. For example, the DB file system can add characters to each file name to create a unique file name. Therefore, Example.doc618 can be presented as Example.doc1, while Example.doc622 is presented as Example.doc2. Rather than adding characters that do not convey specific information, additional characters may be selected to convey meaning. For example, the characters you add may indicate the path to the directory where the file is statically located. That is, Example.doc618 can be represented as Example.doc_Windows (R) _Word, while Example.doc622 is represented as Example.doc_VMS_App4. Alternatively, it is possible to simply force the stored query directory to break the rules of the OS file system. [0137] In the example shown in FIG. 10, all child files in a given directory are either statically specified or all specified by a stored query. However, according to one embodiment of the invention, a directory may have some statically defined child files and some statically defined child files. For example, instead of having a null Dir_entry_list, index entry 1004 can have a Dir_entry_list that statically identifies one or more child files. Therefore, when an application asks the database system to identify a child in the Documents directory, the database server will list a collection of statically defined child files and child files that satisfy the stored query 1002. [0138] Importantly, a stored query that identifies a child file in one directory may select another directory and document. Some or all of such other directories can themselves be stored query directories. Under certain circumstances, a stored query in a particular directory may select that particular directory itself and make that directory its own child. [0139] Since the child files in the stored query directory are determined on the fly, the listing of the child files will always reflect the current state of the database. For example, suppose the "Documents" stored query directory was created as described above. Whenever a new file with the .doc extension is created, it automatically becomes a child of the Documents directory. Similarly, if a file has a .doc extension changed to .txt, the file will automatically be disqualified as a child of the Documents directory. [0140] According to one embodiment, the query associated with a stored query directory may select a particular database record that is a child file of the directory. For example, a directory entitled "Employees" can be linked to a stored query that selects all rows from the Employees table in the database. 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. [0141] Stored query document Just as stored queries can be used to identify child files in a directory, stored queries are also used to identify the contents of a document. can be located. With reference to FIGS. 7 and 11, these figures show a file table 710 with a Body column. The Body field is null for the directory. For a document, the Body column contains a BLOB containing 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 for a stored query document, a stored query linked to the row associated with the stored query document is executed. The content of the document is then constructed based on a set of query results. According to one embodiment, the process of constructing a document from query results is done by the renderer as described above. [0142] 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 where some are determined by the results of the query but others are not. You may. For example, the Body field of a line in a document directory may contain a BLOB, while another field contains a link to a stored query. When a request for a file associated with that row is received, the query may be executed and the results of the query may be combined with a BLOB when rendering the file. [0143] Multi-level stored query directory As mentioned above, stored queries may be used to dynamically select child files in a directory. All child files in a directory belong to the same level in the file hierarchy (that is, the level directly below the directory associated with the stored query). According to one embodiment, a stored query associated with a directory can specify multiple levels under the directory. A directory associated with a query that specifies multiple levels is referred to herein as a multi-level stored query directory. [0144] 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, separate hierarchical levels may be provided 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 criteria. In this example, the first grouping criterion is "department". Thus, the child files of the directory may have different department values, namely "Dept1", "Dept2" and "Dept3". These child files are themselves represented as directories. [0145] The child files in the department directory will be defined by the second grouping criteria. In this example, the second grouping criterion is "region". Therefore, each department directory will have child files for each of the regional values such as "North", "South", "East", and "West". Regional files are also represented as directories. Finally, the child files for each regional directory are the files that correspond to a particular department / regional combination associated with the regional directory. For example, a child of the \ Dept1 \ East directory would be an employee in Department 1 in the East region. [0146] For child files in the stored query directory Handling of file operations As mentioned above, the child files in the stored query directory are presented to the application in a manner similar to the child files in the traditional directory. However, some file operations that can be performed on child files in a traditional directory pose special problems when performed on child files in a stored query directory. [0147] For example, suppose a user makes an input specifying that a child file in a stored query directory should be moved to another directory. This operation is problematic because the child files belong to the stored query directory due to the fact that they meet the criteria specified in the stored query associated with the directory. Unless the file is modified in such a way that it no longer meets its criteria, it will continue to qualify as a child file in the stored query directory. [0148] A similar problem arises when an attempt is made to move a file to a stored query directory. If the file is no longer a child of the stored query directory, then the file does not satisfy the stored query associated with the stored query directory. The file should not be a child of the stored query directory unless it is modified in such a way that the file meets the criteria specified by the stored query. [0149] Various approaches can be taken to solve these problems. For example, you may configure your DB file system to give an error in response to an operation that attempts to move a file into or out of a stored query directory. Alternatively, the DB file system may delete the file in question (or the database record represented as a file) in response to such an attempt. [0150] In yet another approach, files moved into a stored query directory may be automatically modified to meet the criteria for the stored queries associated with the directory. For example, suppose 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. [0151] Similarly, files moved out of a stored query directory may be automatically modified so that they no longer meet the criteria for stored queries associated with the directory. For example, if a file in the Stored Query directory for Married Employee is moved out of that directory, the Married field in the corresponding employee record will be updated to indicate that the employee is not married. To do. [0152] If an attempt is made to move a file that does not meet the criteria of the stored query into the corresponding stored query directory, another approach is to update the index entry in the stored query directory and make the file a child of the stored query directory. Statistical establishment can be mentioned. Under these circumstances, the stored query directory contains some child files that are child files because they satisfy the stored query, and other child files that are child files because they were manually moved to the stored query directory. Will have. [0153] 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) that is 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 determine the contents of the file may include stored database queries, as in the case of stored query files, and / or other code. According to one embodiment, the code associated with the programmatically defined file implements the following routine: [0154]<img file="JP5113967B2_D0001.tif" />The resolve_filename routine returns a file handle for a file that has the name "filename" and is a child of a programmatically defined file. 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 defined file. The put routine inserts data into a programmatically defined file. The delete routine deletes a programmatically specified file. [0155] According to one embodiment, a "resolve_pathname (path): file_handle" routine is also provided. The resolve_pathname routine takes a path and iteratively calls the resolve_filename function for each filename in the path. [0156] According to one embodiment, the DB file system provides an object class that implements the routines listed above for traditional files (ie, non-programmatically defined files). For purposes of explanation, the object class will be referred to here as the "directory class". A subclass of the directory class is established to implement the files specified programmatically. Its subclasses inherit the routines of the directory class, but allow programmers to override the implementation of these routines. The realization provided by the subclass determines the operations performed by the DB file system in response to the file operations involving the programmatically defined files. [0157] Event notification in the file system According to one aspect of the invention, there is provided a file system in which the user is proactively notified when a file system event occurs. These are proactively notified, eliminating the overhead of repeated polling to detect conditions that indicate that an event of interest has occurred. The ability to be notified when a file system event occurs is very useful, for example, when a particular file system event has important implications for the user. [0158] For example, it is common for multiple copies of a document to be maintained (cached) in different locations to provide more efficient access to the document. Under these conditions, if one of the copies is updated, the remaining copies will be out of date (ie, these copies no longer reflect the current state of the document). Using the event notification method described below, when one copy is updated, sites with other copies can be proactively notified of the update. The process or user at these sites may then take any action appropriate in that situation. In the case of caching, the appropriate action may be, for example, to replace the cached version of the document with an updated version. [0159] As another example, a particular user may be responsible for reviewing all of a company's technical documentation before they are published. The company's technical writer may have been instructed to store all technical documentation in the "Ready to Review" directory when the user is ready for review. Without a proactive notification system, simply storing a technical document in the "ready to review" directory would not make the user aware that the new document was 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 regularly checking the "ready to review" directory. On the other hand, in the file system that realizes the event notification method described here, the user is informed that the new technical document is ready to be reviewed by putting the technical document in the "Ready to review" directory. It can trigger the generation of a message to the user for notification. [0160] According to one embodiment of the invention, rules may be defined for proactively generating messages for file system events. Such events include, for example, storing or creating files in a particular directory, deleting files in a particular directory, moving files from a particular directory, modifying or deleting certain files, and certain specifics. Includes linking files to your directory. These file system operations are merely representative. Certain operations in which proactive notification rules can be created can vary from implementation to implementation. The present invention is not limited to providing event notification support for any particular set of file system operations. [0161] According to one embodiment, event_id is assigned to a file system event. Therefore, a notification rule that identifies a certain event_id and a pair of one or more subscribers may be created. Once a rule is registered with the file system, a message is automatically sent to the set of consumers identified in that rule in response to the occurrence of a file system event identified by the rule's event_id. [0162] For example, a user may register an interest in knowing when a file will be added to a particular directory. To record this interest, the database server (1) inserts a row into the "registration rules" table, (2) sets a flag associated with the directory, and at least one rule is against that directory. Indicates that it has been registered. Rows inserted into the table of registered rules identify an entity and indicate the events that the entity is interested in. The line may also contain additional information such as the protocol to be used to communicate with that entity. A flag indicating that a rule applies to a directory may be stored in a table row of files associated with the directory, in a hierarchical index entry associated with the directory, or both. [0163] When inserting a file into a directory, the database server checks the flags associated with the directory to determine if any rules are registered for that directory. If a rule is registered for that directory, the table of registered rules is searched to find a specific rule that applies to that directory. If the registered rules contain rules that apply to a particular operation being performed on the directory, a message is sent to the interested entity identified by these rules. The protocol used to send a message to an entity can vary from entity to entity. For example, for one entity the message may be sent via CORBA, while for other entities the message may be sent in the form of an HTML page over HTTP. [0164] According to one embodiment, the notification mechanism is "for message queues in database systems" submitted by Chandra et al. On October 31, 1997, all of which is incorporated herein by reference. As described above, using a queuing mechanism such as the queuing mechanism described in US Patent Application No. 08 / 961,597 entitled "APPARATUS AND METHOD FOR MESSAGE QUEUING IN A DATABASE SYSTEM". It is realized together with a database-realized file system. [0165] According to one such embodiment, an event server running outside the database server is registered as a subscriber to the queue managed by the database server. The queue to which the event server joins is referred to here as the file event queue. An entity that is interested in a particular file system event registers that interest with the event server. The event server communicates with the database server via the database API and communicates with interested entities via the protocols supported by those entities. [0166] When a database server performs an operation related to a file system, it puts a message in the database server file event queue indicating the event_id associated with the operation. The queue 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 entity has registered interest in the event identified in the message. The event server then sends a message indicating that a file system event has occurred to all entities that have registered interest in the event. [0167] In an embodiment where an event server is used to forward a message to an interested entity, the event server may be configured to support a particular maximum number of users. If the number of interested users exceeds the maximum, it will start an additional event server to serve additional users. As in the case of a single event server, each event server in a multi-event server system is registered as a subscriber to the file event queue. [0168] 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 have registered interest in the particular event associated with the message, and selectively sends the message only to those entities. For entities that do not support the database API, the registration information includes information about the protocols supported by these entities. The queue mechanism sends file event messages to these entities using the protocols listed in their registration information. [0169] File system event notifications can be applied in a variety of contexts. For example, sometimes it is desirable for the first machine to store a cache of files that reside on the second machine. One of the currently available mechanisms to achieve 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 another machine into that briefcase. Each briefcase has an "update" option that, when selected, causes the file system to compare a copy of the file in the briefcase with a 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 newer copy with the older copy). [0170] Unlike the briefcase mechanism, the file system event notification mechanism allows the file cache to be updated proactively so that the file cache always reflects the current state of the file in its original location. To do. For example, the process that manages the file cache may register interest in updating the original copy of the files contained in the cache. This allows the process to be automatically notified when any of the original files are updated and can immediately respond and copy the updated files into the file cache. .. Similarly, the file system event notification mechanism may be used to mirror one or more directories on the first machine and on the second machine. To use the file system event notification mechanism in this way, the process for maintaining a mirrored directory first makes a copy of the directory and all the files it contains, and then the directory. And register their interest in changes made to the files contained in the directory. When notified that a change has been made to a directory, the process makes the corresponding change to the copy of the directory. Similarly, when notified of changes to any of the files in the mirrored directory, the process makes the corresponding changes to the copy of the files. [0171] For example, if a file is moved from a mirrored directory to a non-mirrored directory, the process removes a copy of the file from the mirrored directory and unregisters interest in that file. Therefore, the process will 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 that 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. [0172] Version control in the 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 large number of documents, each of which is somehow related to the project. [0173] Similarly, within a computer system, users often create a large number of electronic documents, all related to a project. For example, programmers located on many sites around the world may each be working on different parts of the same computer program. The electronic documents they generate for the 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. [0174] Typically, project files will be organized into specific folders. For example, Figure 13 shows an example of how files related to the project "Big Project" are organized in different folders. With reference to Figure 13, folder 1302, entitled Big Project, was created to hold all the files (directories and documents) associated with that project. The child files immediately below Big Project 1302 are the folder source code 1304 and the folder docs 1306. source code1304 contains two directories: LA code1312 for storing the programmer's source code 1316 and source code 1318 located in Los Angeles, and SF code 1314 for storing the programmer's source code 1320 located in San Francisco. docs1306 contains two folders, specs1308 and user manual1310. specs1308 includes specs1322 and specs1324. user manual 1310 contains UM1326. [0175] Often, a file in one project will contain references (eg HTML links) to other files in the same project. These references typically identify other documents using the full pathname of that 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 become invalid. [0176] Due to the presence of inter-document references, newer versions of files are typically stored in the same location with the same name as the older version they replace. In traditional file systems, this process overwrites older versions of files, making it impossible to recover them. Unfortunately, there are many cases where it is desirable to recover an older version of a file. For example, critical information may have been inadvertently removed from a newer version. If it is not possible to recover an older version, the user may have to spend considerable resources to reproduce the lost material, if it can also be reproduced. unknown. In addition, it is often possible to restore the change history for a file, determine when a particular change was made, or what has changed at some point. It is desirable to be able to determine if it has been done. [0177] One aspect of the invention provides a versioning mechanism in which a newer version of a file is stored in the same location in the directory hierarchy with the same name as the older version without overwriting the older version. To. Instead of overwriting the older version, the older version is retained and the user can selectively search for the older version of the file. In addition, older versions are retained in their original location 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 in the same location within a directory hierarchy. [0178] Since the creation of a new version does not change the name or location of the original version, any reference to the first version of the file will continue to indicate the first version of the file even if a newer version of the file is created. Therefore, the interfile references contained within a document refer to the correct version of the referenced document, even if a newer version of the referenced document is created. The fact that file-to-file references remain valid in the versioning process (ie, continue to refer to the correct version of the referenced file) has a significant beneficial effect on the efficiency of file retrieval. Specifically, the referenced file follows references to those contained within other files, rather than requiring a lookup operation to find the appropriate version of the referenced file. You can search directly by. [0179] Similarly, lookup operations need not be involved in the process of determining the contents of a directory at any given time. Since directories are versioned by themselves, selecting a particular version of a directory is simply selecting a member of the directory. The selected version of a directory will contain a direct link to the correct file that belongs to that version of the directory, and thus to the correct version of the file. [0180] It also provides a method for tracking relationships between versions of the same file, even if the file name changes from version to version. In addition to the file name, the File ID and version number are maintained for each version of each file, as described in more detail below. If two files have the same File ID, they are different versions of the same file, even if they have different names. [0181] One aspect of the invention provides a mechanism that allows the user to select a "view" of the project that the user wants to see. The project view represents the project's files as they existed at a given point in time. For example, the default view presented to the user may represent the latest version of all files. Another view may show the version of the file that was up to date a day ago. Another view may represent the version of the file that was up to date a week ago. [0182] 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 file system that uses a file table, such as File Table 710, one column of lines associated with a file may store the version number for that file. Each time a file is created, a line for the file is inserted into the file table 710 and the first predetermined version number (eg 1) is stored in the version field for that line. [0183] When the file is updated, the previous version of the file is not overwritten. Instead, a new row is inserted into the file table for the new version of the file. The line for the new version contains the same File ID, Name and Creation Date as the original line, but with a higher version number (eg 2), a new Modification Date and possibly a different file size. In addition, the blob that stores the contents of the file will reflect the update, but the blob of the original entry will not change. [0184] According to one embodiment, if the 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. This means that updating a file in a directory not only creates a row in the file table for the new version of the file, but also a row in the file table for the new version in the directory. In one embodiment using a hierarchical index, an index entry for the new version of the directory will also be added to the hierarchical index. [0185] If a directory and the 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 new rows to the file table and hierarchical index for the directory's parent directory. This process will continue, with new versions being created for all directories that belong to a project and are on top of updated files in the file hierarchy. [0186] To show how the versioning mechanism responds to updates to files that belong to the project, we assume that all the files shown in Figure 13 are version 1 and that updates have been made to code 1320. As shown in Figure 14, the versioning mechanism responds to updates by creating a new version of code1320'without deleting the original version of code1320. code1320 belongs to SF code directory 1314, so a new version of SF code directory 1314'is created without deleting the original version. Since SF code directory 1314 belongs to source code directory 1304, a new version of source code directory 1304'is created without deleting the original version. Finally, since source code directory 1304 belongs to big project directory 1302, a new version of big project 1302'is created without deleting the original version. [0187] As shown in Figure 14, when a new version of the parent file is created in response to the new version of the child file, the new version of the parent file is not the original version of the updated file, but of the updated file. It continues to have the same children that it had before the update, except that the new version is a child. For example, the new version of code1320'is a child of the new version of SF code1314'. The new version of SF code1314'is a child of the new version of source code1304'. However, the unchanged child file of the original source code 1304 (eg LA code 1312) continues to be a child file of the new version of source code 1304'. Similarly, the new version of source code1304'is a child of the new version of big project1302', but the unchanged child file of the original big project (eg docs1306) remains a child file of the new version of big project1302. [0188] In an embodiment where the file system is implemented using a hierarchical index, the index entry created for the new version of the directory replaces the array entry for the updated child file with the array entry for the new version of the child file. Except for that, it will contain the same Dir_entry_list as the index entry for the previous version of the directory. If the updated child file was a child directory, the Dir_entry_list array entry for the new directory will contain the RowID in the hierarchical index of the index entry for the new version of the child directory. [0189] If a file belonging to a project is moved from one directory in that project to another in that project, the file itself has not changed and no new version of the file will be created. However, both the original directory where the file was moved and the directory where the file was placed have changed. This creates new versions for these directories and all ancestor directories of these directories in the same project. Figure 15 shows the new directory that will be created in response to code 1318 in Figure 13, which is moved from LA code 1312 to SF code 1314. Specifically, new versions of LA code 1312'and SF code 1314' will be created. The new version of LA code1312'does not have code1318 as its child. Rather, code1318 is a child of the new version of SF code1314'. A new source code directory 1304'is created and linked to the new versions of LA code 1312' and SF code 1314'. A new big project directory 1302'is created and linked to the new source code 1304' and the original docs directory 1306. [0190] Using the versioning techniques described above, every time a change is made to a project (eg big project 1302), a new version of the project's root directory is created. Links derived from each version of the root project directory linked all the files that belonged to the project to each other at a particular point in time, and the versions of the files thus linked existed at that particular point in time. The version. For example, see Figure 14, the link derived from big project 1302 reflects the project as it existed before the update to code 1320. The link derived from big project1302'reflects the project as it existed immediately after the update to code1320. Similarly, in Figure 15, the link derived from big project 1302 reflects the project as it existed before moving code 1318 from LA code 1312 to SF code 1314. The link derived from big project1302'reflects the project as it existed immediately after moving code1318 from LA code1312 to SF code1314. [0191] Tagging Unfortunately, the versioning techniques described above cause a significant spike in file versions, especially for directories at higher levels in the project. In some circumstances, such a surge may not be necessary or desirable. Therefore, one embodiment of the present invention provides a mechanism for "tagging" a version of a file. File version tagging indicates that that version of the file should be retained. That is, instead of always keeping the older version of the file when a newer version is created, the older version of the file is only kept if it is tagged. Otherwise, they will be replaced (overwritten) when a newer version is created. [0192] See Figure 13 and assume that code 1320 is untagged. When code1320 is updated, the new version of code is simply replaced by the old version of code. Only if code1320 is tagged will a separate new version of code1320, SF code1314, source code1304 and big project1302 be created, as shown in Figure 14. [0193] In many cases, tags will be applied to all files in a project at the same time. For example, if a particular version of a software program is released, 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 file. [0194] In an embodiment 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 root project directory version to locate a file, any changes to that file will lead to the creation of a new version of that file, while the original version of that file Be retained. Conversely, if the location of a file is verified using an untagged version of the root project directory, any changes to that file will simply overwrite the previous version of the file. [0195] 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, suppose the tag applies to LA code 1312. If code1318 is moved out of LA code1312, a new version of LA code1312 will be created. If code1318 is updated, new versions of both code1318 and LA code1312 will be 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 any of the tagged files in the hierarchy are located without traversing, any changes to that file will overwrite the previous version of that file. [0196] Purge count Another technique for reducing 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 retained for any given file. If a new version is created for a file that has already reached the purge count, the new version of that file overwrites the oldest retained version of that file. Purge counts may be implemented on a per-file system, per-project basis, or per-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 per-project basis, all files in a given project have the same purge count, but different projects can have different purge counts. On a file-by-file basis, different purge counts can be identified for each file. [0197] When used in combination with tagging, the purge counting mechanism can be implemented in a variety of ways. According to one embodiment, tagged files are ignored for the purpose of determining if creating a new version of the file will exceed the purge count, and tagged files are by the purge count mechanism. Will never be deleted. For example, suppose a file has a purge count of 5, that is, there are five versions of that file, and one of these five versions is tagged. When an update is made to the file, the purge count mechanism currently determines that there are only four existing untagged versions of the file, thus separating the file without deleting any of the existing versions. Create a version of. If the same file is updated again, the purge count mechanism determines that there are five existing untagged versions of the file, and thus the oldest untagged version of the file in response to creating a new version. To delete. [0198] Inter-project links Each link has a source file (the file from which the link is extended) and a target file (the file pointed to by the link). In a file hierarchy, the source file for a link is often a directory, and the target file for the link is a file within the directory. However, not all links are between a directory and its children. For example, an HTML file can contain graphic images and hyperlinks to other HTML files. In a file system implemented using a hierarchical index, these hyperlinks can be treated in a similar fashion to directory-document links. [0199] The file system view shows how each project in the file system existed at a particular point in time. However, the time point associated with one project in one view may be different from the time point associated with another project in the same view. This causes problems if the link source file belongs to a different project than the link target file. For example, suppose the view identifies a time T1 for project P1 containing file F1 and a later time T2 for project P2 containing 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 the T1 version of P1. However, since that view identifies T1 for P1, the T1 version of P1 should be used for any operation performed on any file in P1 through that view. [0200] According to one embodiment of the invention, the "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 hierarchical index 510, the inter-project boundary flag may be stored, for example, in each array entry in the index entry Dir_entry_list. [0201] In traversal of the file hierarchy, the inter-project boundary flags of all links are checked before following the 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 will be traversed. If the desired version times are not the same, a search is performed looking for the version of the target file that corresponds to the required version time of the project to which the target file belongs. [0202] For example, the inter-project boundary flag for 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 for P2 is T2, which is not the same as the required version time for P1. Therefore, P1 will not be able to locate it by following the link. Instead, a search will be performed to locate the version of P1 that corresponds to time T1. [0203] According to the alternative embodiment, the inter-project boundary flag is not maintained at all. Instead, each time a link is encountered, the requested 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 will be done looking for the correct version of the target file. [0204] Object-oriented file system In recent years, object-oriented programming has become the standard programming norm. In object-oriented programming, the world is modeled in terms of objects. An object is a record that is combined 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. [0205] Occasionally, 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 hair color attribute, while the dolphin object class may require a fin size attribute. [0206] 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 attributes and methods common to both object classes will appear duplicated in both object classes. Duplicate code in this way is very inefficient, especially if 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 process of revising code. This is because changes made to a common attribute must be duplicated at multiple positions in the code in order to be consistent across all object classes that have that attribute. [0207] Inheritance makes it 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 hierarchical structure. For example, the "animal" object class can 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, the programmer can identify 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, and the animal object class is said to be the "parent" class of the dog and dolphin object classes. [0208] According to one aspect of the invention, a mechanism for applying object-oriented norms, including inheritance, is provided for file systems. Specifically, each file in the file system belongs to a class. The file system class defines, among other things, the type of information that the file system stores about the file. According to one embodiment, a base class is provided. File system users may register other classes there, which may be defined as a base class or a subclass of any previously registered class. [0209] When a new file class is registered with the file system, the file system is effectively extended to support interaction with new types of files and new types of file systems. For example, most email applications expect an email document to have a "priority" property. If the file system does not provide a memory for priority properties, the email application may not work properly for email documents stored in that file system. Similarly, some operating systems may expect certain types of system information to be stored with files. If the file system does not remember that information, the operating system may run into problems. By registering a class that contains all the attributes required to support a particular type of system or protocol (eg, a particular operating system, FTP, HTPP, IMAP4, etc.) with that system or protocol. Accurate and transparent dialogue is possible. [0210] To register a class, information about that class is provided, which is data that identifies the parent class of the class and describes any attributes that the parent class does not have and that the class has. including. The information may also identify a particular way of working for an instance of that class. [0211] An object-oriented file system that allows users to register file classes, supports inheritance between file classes, and stores information about files based on the class to which the file belongs is the context in which the file system itself is realized. It can be realized in various ways depending on the situation. According to one embodiment, the object-oriented file system is provided in the context of a database-enhanced file system as described above. Although various aspects of the object-oriented file system will be described in relation to the database-enhanced embodiment, the object-oriented file system method described here is not limited to such an embodiment. [0212] Realization of database of object-oriented file system According to one embodiment, the database implementation type file system has a base class, and it is possible to register a subclass of the base class in the file system. An exemplary set of file classes is shown with reference to Figure 16. The base class, entitled "Files", contains attributes that are commonly common to all files, including their name, creation date, and modification date. Similarly, the Files class methods include methods for operations that can be performed on all files. [0213] According to one embodiment, the attributes of the Files class are a merger of all attributes maintained by the operating system with which the database-enabled file system will be used. For example, suppose the file system is implemented in the database maintained by server 204 as shown in Figure 3. The files stored in that file system originate from operating systems 304a and 304b, but these operating systems do not necessarily support the same set of file attributes. As a result, the set of attributes in the Files class of the file system provided by database server 204 is a merger of the set of attributes supported by the two operating systems 304a and 304b. [0214] According to an alternative embodiment, the attributes of the Files class are the intersection of all attributes maintained by the operating system with which the database-enabled file system is used. In such an embodiment, a subclass of the Files class can be registered for each operating system. Subclasses registered for a given operating system 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. [0215] In the example illustrated in FIG. 16, two subclasses of Files, the "Document" class and the "Folder" class, are registered. The Document class inherits all the attributes and methods of the Files class and adds attributes specific to the document file. In the illustrated embodiment, the Document class adds the attribute "size". [0216] 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 that 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 contained within a given folder. The dir_list method may, for example, provide a complete list of child files in a given folder. [0217] In the class hierarchy illustrated in FIG. 16, the Document class has two registered subclasses, e-mail and Text. Both of these subclasses inherit all of the attributes and methods of the Document class. In addition, the e-mail class contains three additional properties: Read_flag, Priority and Sender. The Text class has one additional attribute, CR_Flag, and an additional method, Type. CR_Flag may be a flag indicating whether the text document contains a "carriage return" symbol. The Type method outputs a text document to an input / output device such as a computer monitor. [0218] File class and file format The internal structure of a file is called the "format" of the file. Typically, the format of the file is determined by the application that creates the file. For example, a document created by one word processor may have the same meaning as another document created by another word processor, but may have a completely different format. Some file systems maintain a mapping between the document format and the filename extension. For example, all files with filenames ending in .doc are presumed to be files created by a particular word processor, and thus have an 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. [0219] In contrast to the file format, the file class mechanism described here is not related to the internal structure of the document. Rather, the file class of a file determines what information the file system maintains for the file and what operations the file system can perform on the file. For example, any document created by many word processors can be an instance of the Document class. This allows the file system to maintain the same attribute information for a document and perform the same operations on the document, even if the internal structure of the document is completely different. [0220] Class table According to one embodiment, the object-oriented file system is implemented in a relational database system in which relational tables are created for each class of file. FIG. 17 is an example of a table that can be created for the class illustrated in FIG. Specifically, the Files table 1702, the document table 1704, the E-mail table 1706, the Text table 1708, and the Folder table 1708 correspond to the Files class, the Document class, the E-mail class, the Text class, and the Folder class, respectively. [0221] According to one embodiment, the class table for a given class is for (1) files that belong to that given class and (2) files that belong to any descendant class of that given class. Includes the line. For example, in the illustrated system, the Files class is the base class. Therefore, all files in the file system are members of the Files class or its descendants. Therefore, the Files table will contain rows for all files in the file system. On the other hand, the E-mail and Text classes are descendants of the Document class, but the Files and Folder classes are not. Therefore, the Document table 1704 contains lines for all files of class Document, E-mail, or Text, but not for files that belong to class Files or Folder. [0222] The table for each class contains 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 and adds a size attribute to these attributes. Therefore, the Document table contains 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 contains columns for storing read_flag values, priority values and sender values. [0223] 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 line X1. Since File1 is an instance of the Files class, the Files table 1704 is the only class table that contains information about File1. Therefore, the only attribute value stored for File1 is the value for the attribute associated with the Files class. [0224] 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 line X2. Since File2 is an instance of the Document class, Files table 1702 and Document table 1704 contain information about File2. That is, the attribute value stored for File2 is the value for the attribute associated with the Document class, including the attribute inherited from the Files class. [0225] The file named File3 is stored in RowID X3 in Files table 1702. The FileID of File3 is F3. The File3 class is the E-mail class, as indicated by the value stored in the Class column on line X3. Since File3 is an instance of the E-mail class, the Files table 1702, Document table 1704, and E-mail table 1706 all contain information about File3. That is, the attribute values stored for File3 are the values for the attributes associated with the E-mail class, including the attributes inherited from the Document and Files classes. [0226] The file named File4 is stored in RowID X4 in Files table 1702. FileID of File4 is F4. The File4 class is the Text class, as indicated by the value stored in the Class column on line X4. Since File4 is an instance of the Text class, Files table 1702, Document1704 and Text table 1708 contain 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. [0227] The file named File5 is stored in RowID X5 in Files table 1702. FileID of File5 is F5. The File5 class is the Folder class, as indicated by the value stored in the Class column on line X5. Since File5 is an instance of the Folder class, Files table 1702 and Folder table 1708 contain 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. [0228] According to one embodiment of the invention, the files in the class table are accessed by traversing the hierarchical index as described above in relation to FIGS. 5 and 8. Traversing the hierarchical index (as done in pathname derivation) produces the RowID of the row in the Files table 1702 that corresponds to the target file. From that line, the attribute value for the Files class attribute is searched. However, for files belonging to other classes, additional attributes may have to be retrieved from the other class table. For example, for File3, the creation and modification dates can be found in row X3 of Files table 1702. However, to find the size of File3, you must access row Y2 in Document table 1704. To find the priority information for File3, you must access row Q1 of E-mail table 1706. [0229] Lines containing these attributes are linked together to facilitate the retrieval of various attribute values that belong to a file. In the illustrated embodiment, the link is stored in a column labeled "Derived Row ID". The value stored in the Derived RowID field of a row for a particular file in a table for a particular class points to a row for that particular file that exists in the table for a subclass of that particular class. For example, the Derived RowID field in the Files table row X3 for File3 contains the value Y2. Y2 is the RowID of the row for File3 in the Document table 1704. Similarly, the Derived Row ID field in Document row Y2 contains the value Q1. Q1 is the RowID of the row for File3 in the E-mail table 1706. [0230] In the illustrated embodiment, the link between rows for a particular file is one-way, going from a row in the table for the parent class to a row in the table for the subclass. These one-way links make it easier to search from a row in the base table (ie file table), which is true under most conditions. However, if the search starts in a row in another table, the relevant row in the parent class table cannot be located by link. A search of these tables may be performed based on the FileID of the file of interest to find these relevant rows. [0231] For example, suppose a user wants to find row Y2 in Document table 1704 and find all other attribute values for File3. A row containing an attribute value specific to E-mail may be found by following a pointer in the Derived Row ID field of row Y2, which points to row Q1 in the E-mail table 1706. However, to find the remaining attributes, search the Files table 1702 based on FileID F3. Such a search will find line X3, which contains the remaining attribute values of File3. [0232] According to an alternative embodiment, links between related lines may be implemented in such a way that all related lines can see their location without a FileID lookup. For example, each class table may also have a Parent RowID field that contains the RowIDs of related rows in the parent class table. Therefore, the Parent Row ID field for row Y2 in Document table 1704 points to row X3 in Files table 1702. Alternatively, the last row in the chain of one-way links may contain a pointer back to the relevant row in the Files table. Yet another option includes providing each class table with a column containing a pointer back to the relevant row in the Files table. Therefore, row R1 of Text table 1708 and row Y3 of Document table 1704 both contain a pointer back to row X4 of Files table 1702. [0233] Subclass registration As mentioned above, registering a new class provides a mechanism for extending the class hierarchy of the file system. In general, the information provided in the class registration process includes data that identifies the parent class of the new class and data that describes the attributes added by the new class. Optionally, the data may also contain data used to identify new methods that can be performed on instances of the new class. [0234] The 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 graphic user interface that contains icons that represent all of the registered classes, and the user can manipulate the controls represented by the user interface to (1) make one of the classes new. You can also choose as the parent of a class, (2) name the new class, (3) define additional attributes for the new class, and (4) define new methods that can be done for the new class. Good. Alternatively, the user may give the file system 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. [0235] According to one embodiment of the invention, class registration information is brought to the file system in the form of an Extensible Markup Language (XML) file. The XML format is described in detail at www.oasis-open.org/cover/xml.htm1#contents and the sites listed there. In general, XML language includes tags that name fields and mark the beginning and end of fields and values for these fields. For example, an XML document that contains registration information for the "Folder" file class may contain the following information: [0236]<img file="JP5113967B2_D0002.tif" />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 columns for each of the attributes defined in the registration information. In this example, only the max_children attribute is defined. The data type specified for the max_children attribute is "integer". Therefore, the Folder table is created with a max_children field that holds integer values. In addition to the attribute names and types, various other information may be provided for each attribute. For example, the registration information may indicate a range or maximum length for an attribute value, indicating whether the field should be indexed or whether the field should be unique or referentially constrained. May be good. [0237] Registration information also includes information about any method supported by the new class files. According to one embodiment, new methods are identified by identifying files containing routines associated with these methods. According to one embodiment, the routine associated with each file class is implemented in the JAVA (R) class. If the first file class is a subclass of the second file class, then the JAVA (R) class that implements the method associated with the first file class is the JAVA (R) class that implements the method of the second file class. Is a subclass of. [0238] In the XML example given above, the dbi_classname field in the registration information identifies the JAVA (R) class file for the Folder file class. Specifically, the registration information brings the file name "my_folder_methods" to the dbi_classname field, my_folder_methods Indicates that the JAVA (R) class implements routines for 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 methods for the Files class. Therefore, the my_folder_methods class inherits the Files method. [0239] In addition to defining new methods that are not supported by the parent file class, routines for child file classes can override the implementation of the methods defined in the parent class. For example, the Files class shown in Figure 16 provides a "memory" method. The Folder class inherits that storage method. However, the implementation of the storage method provided for the Files class may not be the implementation required to store folders. Therefore, the Folder class may provide its own implementation of the storage method, thereby overriding the implementation provided by the Files class. [0240] Judgment of file class 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 a particular class of the file to which the file belongs. As mentioned above, the same operation can be achieved in different ways for different file classes, for example when a subclass overrides the implementation brought about by its parent class. That is, to ensure that the correct operation is performed, the file system must first identify the class of file in which the operation should be performed. [0241] For files that are already stored in the file system, the task of identifying the file's class may be trivial. For example, in the embodiment shown in FIG. 17, the Files table 1702 includes, for any given row, a Class column that stores data indicating the class of files associated with that row. Therefore, when it receives a request to perform a "move" operation on File3, it checks the Class column on line X3 to determine that File3 is of type E-mail. This should carry out the realization of "move" e-mail. The "move" E-mail implementation is the implementation that the E-mail file class brings to the E-mail file class if it overrides the implementation of its inherited "move" method. Otherwise, the "move" E-mail implementation is an implementation inherited by the E-mail class. [0242] The task of identifying the class of a file can be more difficult if the file is no longer stored in the file system. For example, when a file system is required to store a file that no longer exists in the file system, the file system cannot make a class determination by inspecting the file table. Under these conditions, various techniques may be used to identify the type of file. According to one embodiment, the file type can be explicitly introduced in the file operation request. For example, if a request is made in response to a command issued through an operating system command line, one of the command-line arguments can be used to indicate the file type of the file. Good. For example, the command may be entered as "move a: \ mydocs \ file2c: \ yourdocs / class = document". [0243] 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 a certain extension (eg doc.wpd.pwp) may be treated as members of a particular file class (eg Document). Therefore, when a file system is required to perform an operation on these files, a method implementation associated with that particular file class is used. [0244] 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, any file created in 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 techniques may be combined in various ways. For example, a file with a particular extension may be treated as a member of the first class unless the file is stored in the directory associated with the second class. If the file is stored in a directory associated with the second class, then the file is in the second class unless the file operation request explicitly identifies that the file is a member of another file class. Is treated as a member of. [0245] Hardware appearance FIG. 18 is a block diagram showing a computer system 1800 in which an embodiment of the present invention can be realized. Computer system 1800 includes bus 1802 or other communication mechanism for communicating information, and processor 1804 coupled to bus 1802 for processing information. Computer system 1800 also includes main memory 1806, such as random access memory (RAM) or other dynamic storage, which is coupled to bus 1802 to store 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 the execution of instructions to be executed by processor 1804. Computer system 1800 further includes read-only memory (ROM) 1808 or other static storage device coupled to bus 1802 to store static information and instructions for processor 1804. A storage device 1810, such as a magnetic disk or optical disk, is provided and coupled to bus 1802 to store information and instructions. [0246] Computer system 1800 may be coupled via bus 1802 to a display 1812, such as a cathode ray tube (CRT), for displaying information to computer users. The input device 1814, which contains alphanumeric keys and other keys, is coupled to bus 1802 to communicate information and command selection to processor 1804. Another type of user input device is a cursor control 1816, such as a mouse, trackball or cursor direction key, which communicates direction information and command selection to the processor 1804 and controls cursor movement on the display 1812. This input device typically has two degrees of freedom on the first axis (eg x) and the second axis (eg y), which allows the device to locate in a plane. to enable. [0247] The present invention relates to the use of computer system 1800 to implement the techniques described herein. 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. Execution of a sequence of instructions contained in main memory 1806 causes processor 1804 to perform the process steps described herein. In alternative embodiments, wire circuits may be used in place of or in combination with software instructions to realize the present invention. As such, the embodiments of the present invention are not limited to any particular combination of hardware circuits and software. [0248] As used herein, the term "computer-readable medium" refers to any medium involved in providing instructions to processor 1804 for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical or magnetic disks such as storage device 1810. Volatile media include dynamic memory such as main memory 1806. Transmission media include coaxial cables, copper wires and optical fibers, including the wiring that makes up bus 1802. The transmission medium may also take the form of sound waves or light waves, such as those produced in radio and infrared data communications. [0249] Common forms of computer-readable media include, for example, floppy (R) disks, flexible disks, hard disks, magnetic tape or all other magnetic media, CD-ROMs, all other optical media, perforated cards, paper tape, holes. Includes all other physical media with patterns, RAM, PROM and EPROM, FLASH-EPROM and all other memory chips or cartridges, carriers as described below or all other media readable by a computer. [0250] Various forms of computer-readable media can be involved in giving processor 1804 one or more sequences of one or more instructions for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. A remote computer can load instructions into its dynamic memory and send the instructions over a telephone line using a modem. The modem of the computer system 1800 can receive the data on the telephone line and use the infrared transmitter to convert the data into an infrared signal. The infrared detector receives the data on the infrared signal and the appropriate circuit can output that data on bus 1802. Bus 1802 carries data to main memory 1806, from which processor 1804 retrieves and executes instructions. Instructions received by main memory 1806 may optionally be stored in storage device 1810 either before or after execution by processor 1804. [0251] Computer system 1800 also includes a communication interface 1818 coupled to bus 1802. Communication interface 1818 provides bidirectional data communication coupled to network link 1820 connected to local network 1822. For example, the communication interface 1818 may be a modem or integrated services digital network (ISDN) card that provides a data communication connection to the corresponding type of telephone line. As another example, the communication interface 1818 may be a local area network (LAN) card for providing a data communication connection to a compatible LAN. Wireless links can also be realized. In any of these implementations, the communication interface 1818 sends and receives electrical, electromagnetic or optical signals carrying digital data streams that represent different types of information. [0252] Network link 1820 typically provides data communication to other data devices over one or more networks. For example, network link 1820 may provide a connection to a host computer 1824 or to a data device operated by an Internet Service Provider (ISP) 1826 over a local network 1822. The ISP 1826 provides data communication services over the worldwide packet data communication network now commonly referred to as the "Internet" 1828. Both local networks 1822 and the Internet 1828 use electrical, electromagnetic or optical signals that carry digital data streams. Signals over various networks and on network link 1820 that exchanges digital data with computer system 1800 and over communication interface 1818 are exemplary forms of carrier waves that carry information. [0253] Computer system 1800 can send messages and receive data, including program code, via networks, network links 1820 and communication interfaces 1818. In the Internet example, server 1830 might send the requested code for an application program through Internet 1828, ISP1826, local network 1822 and communication interface 1818. According to the present invention, one such downloaded application implements the technique described herein. [0254] The received code may be executed by processor 1804 as it is received and / or stored in storage device 1810 or other non-volatile storage for later execution. In such an embodiment, the computer system 1800 may obtain an application code in the form of a carrier wave. [0255] In the above specification, the invention has been described in the context of its particular embodiment. However, it will become clear that various changes and modifications may be made to this without departing from the broader spirit and scope of the invention. The specification and drawings should therefore be viewed in an exemplary sense and not in a limited sense. [Simple explanation of drawings] FIG. 1 is a block diagram showing how data is stored through a file system provided by an operating system in a conventional application. 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 showing a system in which the same set of data can be accessed through various interfaces including the database API and the OS file system API. FIG. 4 is a block diagram showing a translation engine 308 in more detail. FIG. 5 is a block diagram showing a hierarchical index. [Fig. 6] It is a block diagram which shows the file hierarchical structure which can be emulated by the hierarchical index. FIG. 7 is a block diagram showing a file table that can be used to store files in a relational database according to an embodiment of the present invention. FIG. 8 is a flowchart showing a step of deriving a path name using a hierarchical index. FIG. 9 is a block diagram showing a database file server in more detail. FIG. 10 is a block diagram of a hierarchical index containing entries for a stored query directory. FIG. 11 is a block diagram of a file table containing rows for a stored query directory. FIG. 12 is a block diagram showing a file hierarchy including a stored query directory. FIG. 13 is a block diagram showing a file hierarchical structure. FIG. 14 is a block diagram showing how the file hierarchy shown in FIG. 13 is updated in response to an update of a document according to an embodiment of the versioning technique described here. [Fig. 15] FIG. 3 is a block diagram showing how the file hierarchy shown in FIG. 13 is updated in response to moving a document from one folder to another according to an embodiment of the versioning technique described here. FIG. 16 is a block diagram showing a class hierarchical 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 a database-realized file system that realizes the file class hierarchical structure of FIG. 16 according to an embodiment of the present invention. FIG. 18 is a block diagram showing a computer system in which an embodiment of the present invention can be realized.
5 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5
Every citation, both waysCites: the store holds 1 of 2
| Document | Relation | Office |
|---|---|---|
| JP10247155A | Cites | Japan |
| 水吉 俊幸,C/Sシステムの性能を引き出すためのネットワーク設計(I),日経オープンシステム,日本,日経BP社,1995年4月15日,第25号,p. 287~298 | Non-patent | – |
| すずき ひろのぶ,Linuxで理解するOS講座 No.2,SoftwareDesign,日本,株式会社技術評論社,1999年2月18日,第100号,p.76~80 | Non-patent | – |
| 木村 憲雄,ネットワーク・ファイル・システムの研究,OPEN DESIGN No.5 第2版,日本,CQ出版株式会社,1996年6月20日,p.100~137 | Non-patent | – |
189 members in 10 offices
Priority claims44
| Document | Office | Kind | Date |
|---|---|---|---|
| 14753899 | United States of America | P | |
| 14753899 | United States of America | P | |
| 60147538 | United States of America | – | |
| 09571036 | United States of America | – | |
| 09571060 | United States of America | – | |
| 09571492 | United States of America | – | |
| 09571496 | United States of America | – | |
| 09571508 | United States of America | – | |
| 09571568 | United States of America | – | |
| 09571696 | United States of America | – | |
| 57103600 | United States of America | A | |
| 57103600 | United States of America | A | |
| 57106000 | United States of America | A | |
| 57106000 | United States of America | A | |
| 57149200 | United States of America | A | |
| 57149200 | United States of America | A | |
| 57149600 | United States of America | A | |
| 57149600 | United States of America | A | |
| 57150800 | United States of America | A | |
| 57150800 | United States of America | A | |
| 57156800 | United States of America | A | |
| 57156800 | United States of America | A | |
| 57169600 | United States of America | A | |
| 57169600 | United States of America | A | |
| 0020386 | United States of America | W | |
| 0020386 | United States of America | W | |
| 1999147538 | – | – | – |
| 2000571036 | – | – | – |
| 2000571060 | – | – | – |
| 2000571492 | – | – | – |
| 2000571496 | – | – | – |
| 2000571508 | – | – | – |
| 2000571568 | – | – | – |
| 2000571696 | – | – | – |
| 2000020386 | – | – | – |
| US19990147538P | – | – | – |
| US20000571036 | – | – | – |
| US20000571060 | – | – | – |
| US20000571492 | – | – | – |
| US20000571496 | – | – | – |
| US20000571508 | – | – | – |
| US20000571568 | – | – | – |
| US20000571696 | – | – | – |
| WO2000US20386 | – | – | – |
Members189
| Document | Office | Kind | |
|---|---|---|---|
| CA2359880A1 | Canada | A1 | |
| WO0049533A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU3596700A | Australia | A | |
| CA2379930A1 | Canada | A1 | |
| CA2646776A1 | Canada | A1 | |
| CA2650251A1 | Canada | A1 | |
| WO0111486A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU6495400A | Australia | A | |
| WO0049533A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1145143A2 | European Patent Office (EPO) | A2 | |
| CA2422887A1 | Canada | A1 | |
| WO0227561A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU9489601A | Australia | A | |
| US6427123B1 | United States of America | B1 | |
| JP2003505748A | Japan | A | |
| US2003033285A1 | United States of America | A1 | |
| US2003037056A1 | United States of America | A1 | |
| CA2462300A1 | Canada | A1 | |
| US2003065659A1 | United States of America | A1 | |
| WO03027908A2 | World Intellectual Property Organization (WIPO) | A2 | |
| CA2461854A1 | Canada | A1 | |
| CA2461871A1 | Canada | A1 | |
| WO03030031A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO03030032A2 | World Intellectual Property Organization (WIPO) | A2 | |
| US6549916B1 | United States of America | B1 | |
| WO0111486A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US6571231B2 | United States of America | B2 | |
| AU762942B2 | Australia | B2 | |
| US2003140308A1 | United States of America | A1 | |
| EP1330727A2 | European Patent Office (EPO) | A2 | |
| WO0227561A3 | World Intellectual Property Organization (WIPO) | A3 | |
| JP2003527659A | Japan | A | |
| US6631374B1 | United States of America | B1 | |
| EP1358579A2 | European Patent Office (EPO) | A2 | |
| WO03027908A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO03030031A3 | World Intellectual Property Organization (WIPO) | A3 | |
| HK1056634A | Hong Kong, China | A | |
| HK1056634A1 | Hong Kong, China | A1 | |
| US2004064466A1 | United States of America | A1 | |
| JP2004512585A | Japan | A | |
| WO03030032A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2004088306A1 | United States of America | A1 | |
| US2004088340A1 | United States of America | A1 | |
| US2004088415A1 | United States of America | A1 | |
| AU2001294896B2 | Australia | B2 | |
| CA2504141A1 | Canada | A1 | |
| CA2505156A1 | Canada | A1 | |
| CA2505158A1 | Canada | A1 | |
| WO2004044738A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2004044780A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2004044781A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2003287565A1 | Australia | A1 | |
| AU2003290654A1 | Australia | A1 | |
| AU2003290655A1 | Australia | A1 | |
| AU774090B2 | Australia | B2 | |
| EP1433089A2 | European Patent Office (EPO) | A2 | |
| EP1440394A2 | European Patent Office (EPO) | A2 | |
| EP1446737A2 | European Patent Office (EPO) | A2 | |
| AU2004203240A1 | Australia | A1 | |
| AU2004203241A1 | Australia | A1 | |
| AU2004203242A1 | Australia | A1 | |
| AU2004203243A1 | Australia | A1 | |
| AU2004203249A1 | Australia | A1 | |
| WO2004044780A3 | World Intellectual Property Organization (WIPO) | A3 | |
| CN1561496A | China | A | |
| CN1561497A | China | A | |
| WO2004044781A3 | World Intellectual Property Organization (WIPO) | A3 | |
| JP2005505042A | Japan | A | |
| JP2005505058A | Japan | A | |
| JP2005505059A | Japan | A | |
| CN1585945A | China | A | |
| WO2004044738A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2005055385A1 | United States of America | A1 | |
| US2005065949A1 | United States of America | A1 | |
| US2005091287A1 | United States of America | A1 | |
| US2005114409A1 | United States of America | A1 | |
| US2005120062A1 | United States of America | A1 | |
| US2005120064A1 | United States of America | A1 | |
| AU2003287565A2 | Australia | A2 | |
| US6922708B1 | United States of America | B1 | |
| EP1559006A2 | European Patent Office (EPO) | A2 | |
| EP1559035A2 | European Patent Office (EPO) | A2 | |
| EP1559036A2 | European Patent Office (EPO) | A2 | |
| US6947950B2 | United States of America | B2 | |
| US6950822B1 | United States of America | B1 | |
| US6965903B1 | United States of America | B1 | |
| CN1711534A | China | A | |
| US6983286B1 | United States of America | B1 | |
| CN1717656A | China | A | |
| CN1729467A | China | A | |
| HK1077107A1 | Hong Kong, China | A1 | |
| HK1077108A | Hong Kong, China | A | |
| JP2006505871A | Japan | A | |
| JP2006505872A | Japan | A | |
| JP2006505877A | Japan | A | |
| US7020653B2 | United States of America | B2 | |
| US7028037B1 | United States of America | B1 | |
| US2006101041A1 | United States of America | A1 | |
| US7047250B1 | United States of America | B1 | |
| US7047253B1 | United States of America | B1 |
20 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Re-examination (zenchi) completed and case transferred to appeal boardAppealJAPANESE INTERMEDIATE CODE: A912A912 | A912 | |
| Transfer to examiner for re-examination before appeal (zenchi)AppealJAPANESE INTERMEDIATE CODE: A911A911 | A911 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Decision of refusalJAPANESE INTERMEDIATE CODE: A02A02 | A02 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 | |
| Notification of change in applicantJAPANESE INTERMEDIATE CODE: A711A711 | A711 |
Numbers
- Publication
- 5113967
- Publication, DOCDB
- 5113967
- Publication, EPODOC
- JP5113967B
- Application
- 2001516067
- Application, DOCDB
- 2001516067
- Application, EPODOC
- JP20010516067
Titles2
- Japanese
- インターネットファイルシステム
- English
- Internet file system
Classification
- CPC, 1
- G06F16/10
- IPC, 2
- G06F12 00
- G06F17 30
