Source: http://www.google.com/patents/US8176007?dq=patent:3079728
Timestamp: 2017-11-18 12:43:14
Document Index: 184294543

Matched Legal Cases: ['Application No. 2', 'Application No. 200580018627', 'Application No. 2', 'Application No. 02799692', 'Application No. 600202', 'Application No. 200580018627']

Patent US8176007 - Performing an action in response to a file system event - Google Patents
A method and apparatus for performing an action in response to a file system event is provided. According to one aspect, sets of “event listeners” are associated with a file hierarchy and/or the nodes thereof. Each event listener contains a set of “event handlers.” Each event handler corresponds...http://www.google.com/patents/US8176007?utm_source=gb-gplus-sharePatent US8176007 - Performing an action in response to a file system event
Publication number US8176007 B2
Application number US 13/026,131
Filing date Feb 11, 2011
Also published as US7921076, US20060129584, US20110137963
Publication number 026131, 13026131, US 8176007 B2, US 8176007B2, US-B2-8176007, US8176007 B2, US8176007B2
Inventors Thuvan Hoang, Sam Idicula, Nipun Agarwal, Ravi Murthy, Asha Tarachandani, Namit Jain, Eric Sedlar
Patent Citations (245), Non-Patent Citations (47), Classifications (8), Legal Events (2)
Performing an action in response to a file system event
US 8176007 B2
A method and apparatus for performing an action in response to a file system event is provided. According to one aspect, sets of “event listeners” are associated with a file hierarchy and/or the nodes thereof. Each event listener contains a set of “event handlers.” Each event handler corresponds to a separate type of event that may occur relative to the file hierarchy's nodes. When an event is going to occur relative to the hierarchy or a node thereof, all event listeners that are associated with that hierarchy/node are inspected to determine whether those event listeners contain any event handlers that correspond to the event's type. Those event handlers that correspond to the event's type are placed in an ordered list of event handlers to be invoked. As the event handlers in the list are invoked, programmatic mechanisms that correspond to those event handlers are executed to perform customized user-specified actions.
storing a first event handler that specifies a first method to be performed prior to an occurrence of a file system event of a first event type relative to one or more nodes in a file system, wherein execution of the first method causes a first action to be performed on a first database object;
storing a second event handler that specifies a second method to be performed after an occurrence of a file system event of the first event type relative to the one or more nodes in the file system, wherein execution of the second method causes a second action to be performed on a second database object;
storing one or more event handlers other than the first event handler and the second event handler, wherein the one or more other event handlers correspond to one or more event types other than the first event type;
a server detecting that execution of a received file system command will cause a particular file system event of the first event type relative to the one or more nodes in the file system;
in response to the server detecting that the received file system command will cause the particular file system event of the first event type relative to the one or more nodes in the file system: (a) the server adding the particular file system event to a list of file system events to occur, and (b) the server invoking the first method prior to the occurrence of the particular file system event; and
in response to and after the occurrence of the particular file system event, the server invoking the second method;
wherein the first and second actions differ from the particular file system event;
wherein the first event handler, the second event handler, and the one or more other event handlers are stored in a configuration file, and wherein the configuration file contains an indication of whether a method corresponding to an event identifier is to be performed before or after the occurrence of a file system event;
2. The method of claim 1, wherein a database server manages the file system.
3. The method of claim 1, wherein the configuration file is an extensible markup language (XML) file, and wherein the XML file contains a first tag that indicates “pre” before a particular event identifier to indicate that the first method is to be performed before the occurrence of a file system event that corresponds to the particular event identifier, and wherein the XML file contains a second tag that indicates “post” before the particular event identifier to indicate that the second method is to be performed after the occurrence of a file system event that corresponds to the particular event identifier.
4. One or more non-transitory computer-readable storage media storing instructions which, when executed by one or more processors, cause the one of more processors to perform the steps of:
wherein the first and second actions differ from the particular file system event.
5. The one or more non-transitory computer-readable storage media of claim 4, wherein a database server manages the file system.
6. The one or more non-transitory computer-readable storage media of claim 4, wherein the configuration file is an extensible markup language (XML) file, and wherein the XML file contains a first tag that indicates “pre” before a particular event identifier to indicate that the first method is to be performed before the occurrence of a file system event that corresponds to the particular event identifier, and wherein the XML file contains a second tag that indicates “post” before the particular event identifier to indicate that the second method is to be performed after the occurrence of a file system event that corresponds to the particular event identifier.
7. The method of claim 1, wherein the first database object stores information about the one or more nodes.
8. The method of claim 1, wherein the second database object stores information about the one or more nodes.
9. The method of claim 1, wherein the file system event is an event that occurs when a node of the one or more nodes is locked or unlocked.
10. The method of claim 1, wherein the file system event is an event that occurs when a node of the one or more nodes is dynamically generated.
11. The method of claim 1, wherein the file system event is an event that occurs when a symbolic link to a node of the one or more nodes is established or destroyed.
12. The one or more non-transitory computer-readable storage media of claim 4, wherein the first database object stores information about the one or more nodes.
13. The one or more non-transitory computer-readable storage media of claim 4, wherein the second database object stores information about the one or more nodes.
14. The one or more non-transitory computer-readable storage media of claim 4, wherein the file system event is an event that occurs when a node of the one or more nodes is locked or unlocked.
15. The one or more non-transitory computer-readable storage media of claim 4, wherein the file system event is an event that occurs when a node of the one or more nodes is dynamically generated.
16. The one or more non-transitory computer-readable storage media of claim 4, wherein the file system event is an event that occurs when a symbolic link to a node of the one or more nodes is established or destroyed.
17. The method of claim 1, wherein the first event type is one of: render, create, delete, update, lock, unlock, link in, link to, unlink in, unlink from, check in, check out, uncheck out, version control, inconsistent update, or open; and wherein the one or more other event types include one or more others of: render, create, delete, update, lock, unlock, link in, link to, unlink in, unlink from, check in, check out, uncheck out, version control, inconsistent update, or open.
18. The method of claim 1, wherein the received file system command is one of: a command to copy files, a command to move files, a command to delete files, a command to create directories, a command to list directory contents, a command to remove directories, a command to rename files, or a command to rename directories.
19. The one or more non-transitory computer-readable storage media of claim 4, wherein the first event type is one of: render, create, delete, update, lock, unlock, link in, link to, unlink in, unlink from, check in, check out, uncheck out, version control, inconsistent update, or open; and wherein the one or more other event types include one or more others of: render, create, delete, update, lock, unlock, link in, link to, unlink in, unlink from, check in, check out, uncheck out, version control, inconsistent update, or open.
20. The one or more non-transitory computer-readable storage media of claim 4, wherein the received file system command is one of: a command to copy files, a command to move files, a command to delete files, a command to create directories, a command to list directory contents, a command to remove directories, a command to rename files, or a command to rename directories.
BENEFIT CLAIM; RELATED CASES
This application is a continuation of application Ser. No. 11/014,502, filed Dec. 15, 2004, now U.S. Pat. No. 7,921,076 entitled “PERFORMING AN ACTION IN RESPONSE TO A FILE SYSTEM EVENT,” the entire contents of which is incorporated by reference herein in its entirety.
The present application is related to U.S. Pat. No. 6,427,123, entitled “HIERARCHICAL INDEXING FOR ACCESSING HIERARCHICALLY ORGANIZED INFORMATION IN A RELATIONAL SYSTEM”, filed Feb. 18, 1999; U.S. Pat. No. 6,549,916, entitled “EVENT NOTIFICATION SYSTEM TIED TO FILE SYSTEM”, filed May 15, 2000; U.S. patent application Ser. No. 09/571,060, entitled “BASING DIRECTORY CONTENTS ON A QUERY THAT IS ASSOCIATED WITH A FILE IDENTIFIER”, filed May 15, 2000; U.S. patent application Ser. No. 09/571,696, entitled “VERSIONING IN INTERNET FILE SYSTEM”, filed May 15, 2000; U.S. patent application Ser. No. 10/259,176, entitled “MECHANISM FOR UNIFORM ACCESS CONTROL IN A DATABASE SYSTEM”, filed Sep. 27, 2003; U.S. patent application Ser. No. 10/260,381, entitled “MECHANISM TO EFFICIENTLY INDEX STRUCTURED DATA THAT PROVIDES HIERARCHICAL ACCESS IN A RELATIONAL DATABASE SYSTEM”, filed Sep. 27, 2002; U.S. patent application Ser. No. 10/306,485, entitled “TECHNIQUES FOR MANAGING HIERARCHICAL DATA WITH LINK ATTRIBUTES IN A RELATIONAL DATABASE”, filed Nov. 26, 2002; U.S. patent application Ser. No. 10/884,311, entitled “INDEX FOR ACCESSING XML DATA”, filed Jul. 2, 2004; U.S. patent application Ser. No. 10/944,177, entitled “INDEX MAINTENANCE FOR OPERATIONS INVOLVING INDEXED XML DATA”, filed Sep. 16, 2004; U.S. patent application Ser. No. 10/944,170, entitled “EFFICIENT QUERY PROCESSING OF XML DATA USING XML INDEX”, filed Sep. 16, 2004; U.S. patent application Ser. No. 10/452,164, entitled “TRANSACTION-AWARE CACHING FOR ACCESS CONTROL METADATA”, filed May 30, 2003; U.S. patent application Ser. No. 10/452,163, entitled “TRANSACTION-AWARE CACHING FOR FOLDER PATH DATA”, filed May 30, 2003; U.S. patent application Ser. No. 09/728,909, entitled “HIERARCHY-BASED SECURED DOCUMENT REPOSITORY”, filed Dec. 1, 2000; and U.S. patent application Ser. No. 11/014,442, entitled “A COMPREHENSIVE FRAMEWORK TO INTEGRATE BUSINESS LOGIC AND RULES INTO A REPOSITORY”, filed Dec. 15, 2004; the contents of all of which are hereby incorporated by reference in their entirety for all purposes as if fully set forth herein.
The present invention relates to computer file systems, and in particular, to performing an action in response to a file system event.
Emulating a Hierarchical File System in a Relational Database System
In the directory hierarchy, directory 116 is a child of directory 114 entitled “Windows”, and directory 114 is a child of directory 110. Similarly, directory 124 is a child of directory 126 entitled “VMS”, and directory 126 is a child of directory 110. Directory 110 is referred to as the “root” directory because it is the directory from which all other directories descend. In many systems, the symbol “/” is used to refer to the root directory. Each of directories 110, 114, 116, 120, 124, 126, and each of documents 118 and 122, is a separate node in the directory hierarchy.
Within a file system, the sequence of filenames in a given pathname begins with the name of the root directory, includes the names of all directories along the path from the root directory to the item of interest, and terminates in the name of the item of interest. Typically, the list of directories to traverse is concatenated together, with some kind of separator punctuation (e.g., ‘/’, ‘\’, or ‘;’) to make a pathname. Thus, the pathname for document 118 is/Windows/Word/Example.doc, while the pathname for document 122 is /VMS/App4/Example.doc.
Such emulation may be implemented through the use of two relational tables: a “file” table and a “directory links” table. The file table stores information relating to each file in the emulated hierarchical system. For files that are documents, the file table further stores either the body of the file (in the form of a large binary object (BLOB)), or a pointer to the body of the document. The directory links table stores all of the link information that indicates the parent-child relationships between files.
/ (X1)
The file ID, also known as the “object ID” or “OID,” is a unique ID assigned to each file by the system. The name is the name assigned to the file, which does not need to be unique. The body is the field in which the contents of a file are stored. The body field may store the actual contents of a file in the form of a binary large object (BLOB), or a pointer to the contents of the file. Where the entry is for a file having no content (e.g. a directory), the body field is null. In the above example, only the two documents entitled Example.doc have content; thus, the body field for all of the other entries is null.
In directory links table 310, an entry is stored for each link between files in the file system of FIG. 1. Each entry includes a parent ID, a child ID, and a child_name field. For each link, the parent ID field specifies the file which is the parent file for the link, the child ID field specifies the file which is the child file for the link, and the child_name field specifies the name of the child file in the link. Thus, for example, in the entry for the link between root directory 110 and Windows directory 114, directory links table 310 specifies that X1 (the FileID of the root directory) is the parent ID, X2 (the FileID of the Windows directory) is the child ID, and “Windows” is the child_name.
from directory_links
Where ParentID=“X1”
child_name=“Window”.
Where ParentID=“X2” and
Child_name=“Word”.
Where ParentID=“X3” and
Child_name=“Example.doc”
In a database management system, a trigger is an object that specifies a series of actions to be automatically performed when a specific event occurs. According to industry standards, Data Manipulation (DML) statements—SQL statements that manipulate data in tables—are the events that cause user-defined triggers to be activated (or “fired”). For example, in a relational database, user-defined triggers may be designed to fire when a row of a database table or a table view is updated, inserted, or deleted. Accordingly, each user-defined trigger is typically associated with a single database table. That is, in a conventional database management system, the scope of the user-defined trigger is the table level of the database.
The series of actions specified by a trigger is typically written as instructions in a high-level database language such as SQL or PL/SQL (a procedural language extension of SQL available from Oracle Corporation of Redwood Shores, Calif.). In conformance with industry standards, these instructions must be able to access the data values of table columns corresponding to an affected row before the triggering DML statement was applied (the “old values”) and after the modification was applied (the “new values”).
As is discussed above, triggers may be associated with database tables, and a hierarchical file system may be represented through multiple tables. Unfortunately, triggers are very often unsuitable for specifying actions that are to be performed in response to events that occur relative to nodes in the file system. Events that occur relative to nodes in a file system do not always have a direct and unique correspondence with events that occur relative to the database tables that represent the file system. As a result, it is sometimes difficult to define a database table event that would correspond to a particular event in the file system. Although some events may occur relative to a database table whenever a particular event occurs relative to a file system, those events also might occur relative to the database table even in the absence of the particular event occurring relative to the file system.
Additionally, one or more of the database tables that represent the file system might not be accessible to users. As a result, users might not be able to associate triggers with the database tables that implement the file system. For example, ordinary users might not have sufficient privileges to associate customized triggers with files table 210 and/or database links table 310. Indeed, ordinary users might not understand how events occurring within the file system affect these tables. Ordinary users might be insulated from these tables to such an extent that they would not even be aware of the existence of these tables.
Ordinary users typically do understand hierarchical file systems, though, as well as the operations that can be performed on nodes within those file systems. Under many circumstances, users might find it useful for specified actions to be performed automatically in response to specified events occurring within a file system. A way of causing specified actions to be performed automatically in response to specified file system events is needed.
FIGS. 5A-C show a flow diagram that illustrates a technique, according to an embodiment of the invention, for performing an action in response to a file system event; and
A method and apparatus are described for performing an action in response to a file system event. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
According to one embodiment of the invention, sets of “event listeners” may be associated with individual nodes of a file hierarchy, and/or with the entire file hierarchy. Each event listener contains a set of “event handlers.” Each event handler corresponds to a separate type of event that may occur relative to nodes, such as files and directories, in the file hierarchy.
In one embodiment, when an event is going to occur relative to a node in the file hierarchy, all event listeners that are associated with either the entire file hierarchy or the node relative to which the event is going to occur are inspected to determine whether those event listeners contain any event handlers that correspond to the event's type. Those event handlers that correspond to the event's type are placed in a list of event handlers to be invoked.
Each event handler corresponds to a separate programmatic mechanism. As the event handlers in the list are invoked, the programmatic mechanisms that correspond to those event handlers are executed. Such programmatic mechanisms may be custom-created by users, so that custom user-desired actions are performed in response to events occurring relative to nodes in the file system.
The term “file system event” is defined herein as an event that occurs in response to a file system command being received through a file system interface. Examples of file system commands include commands to copy files, move files, delete files, create directories, list directory contents, remove directories, rename files, and rename directories. Other file system commands are well known. According to one embodiment, a file system command is mapped to one or more corresponding database commands. When issued to a database server, database commands cause the database server to perform operations on database objects such as database tables. These database commands are not received through a file system interface.
According to one embodiment, when a file system command is received through a file system interface, the one or more corresponding database commands are issued to a database server, which performs operations on database objects to carry out the file system command. System tables, which are not directly accessible to users, may be among the database objects upon which such operations are performed. Although a file system command may cause a database server to perform a specific operation relative to a specific database object, under some circumstances, the same specific operation may be performed relative to the same specific database object even in the absence of a file system command. Thus, while database events may occur in conjunction with file system events according to one embodiment, the same database events also may occur exclusively of file system events.
Resource Configurations
In one embodiment, event listeners are associated with a file hierarchy and/or the nodes thereof by associating “resource configurations” with the hierarchy and/or nodes. Each resource configuration contains a list of one or more event listeners. According to one embodiment, each resource configuration is implemented as a separate XML document that conforms to a resource configuration schema.
Shown below is an example resource configuration schema that contains two separate event listeners. Each event listener is bounded by the “<listener>” and “</listener>” opening and closing tags.
<ResConfig xmlns=“http://xmlns.oracle.com/xdb/XDBResConfig.xsd”
xsi:schemaLocation=“http://xmlns.oracle.com/xdb/XDBResConfig.xsd
http://xmlns.oracle.com/xdb/XDBResConfig.xsd”>
<event-listeners default-language=“Java” default-schema=“IFS”>
<description>Category application</description>
<schema>CM</schema>
<source>oracle.cm.category</source>
<Post-LinkIn/>
<Post-UnlinkIn/>
<Post-Update/>
<pre-condition>
<existsNode>
<XPath>/Resource[ContentType=“image/gif”]</Xpath>
</existsNode>
</pre-condition>
<description>Check quota</description>
<source>oracle.ifs.quota</source>
<Post-Update>
<XPath>r:/Resource/[ns:type=“ifs-file”]</XPath>
xmlns:r=“http://xmlns.oracle.com/xdb/XDBResource.xsd”
xmlns:ns=“http://foo.xsd”
</event-listener>
</ResConfig>
In the above example, each “listener” element has a “description” child element that contains a description of the corresponding event listener. This first event listener's description is “Category application” and the second event listener's description is “Check quota”.
Each listener element also has a “source” child element that contains a reference to a programmatic mechanism that implements all of the corresponding event listener's event handling mechanisms. The event handling mechanisms for the “Category application” event listener are implemented by programmatic mechanism “oracle.cm.category”. The event handling mechanisms for the “Check quota” event listener are implemented by programmatic mechanism “oracle.ifs.category”. Such programmatic mechanisms may be instances of Java classes and/or PL/SQL packages, for example.
Each resource configuration may be associated with the entire file hierarchy, or with a specified node of the hierarchy. For example, the resource configuration shown above might be associated with directory 116. If so, then whenever a file system event was going to occur relative to directory 116, the “Category application” and “Check quota” event listeners both would be inspected to determine whether any of those event listeners' event handlers corresponded to the event type of the file system event that was going to occur relative to directory 116. For another example, the resource configuration shown above might be associated with the entire file hierarchy. If so, then whenever a file system event was going to occur relative to any node in the file hierarchy, the “Category application” and “Check quota” event listeners both would be inspected to determine whether any of those event listeners' event handlers corresponded to the event type of the file system event that was going to occur relative to that node.
Each listener element also has an “events” child element. Each such “events” element may contain one or more additional child elements. Each of these child elements corresponds to a separate event handler. For example, in the resource configuration shown above, each event listener has event handlers for “Post-LinkIn,” “Post-UnlinkIn,” and “Post-Update” file system events; these are bounded by the “<events>” and “</events>” opening and closing tags. Each of these event handlers corresponds to a file system event type.
According to one embodiment, whenever a file system event of a particular file system event type is going to occur relative to a particular node in the file hierarchy, the following steps are performed. First, each of the event listeners in the resource configuration associated with the entire file hierarchy is inspected to determine if any of those event listeners contains an event handler that corresponds to the particular file system event type. Event handlers that correspond to the particular file system event type are added to a list of event handlers that are to be invoked. The event handlers are placed in the list in the same order as the order of their event listeners in the resource configuration. Thus, event listeners that occur earlier in a resource configuration have precedence over event listeners that occur later in a resource configuration.
Next, each of the event listeners in the resource configuration associated with the particular node are inspected to determine if any of those event listeners contains an event handler that corresponds to the particular file system event type. Event handlers that correspond to the particular file system event type are added to the list of event handlers that are to be invoked. The event handlers are placed beneath any other event handlers that are already in the list. Thus, event handlers that occur in a resource configuration that is associated with the entire file hierarchy have precedence over event listeners that occur in a resource configuration that is associated with the particular node.
In one embodiment, the addition of a particular event handler to the list of event handlers that are to be invoked is subject to the satisfaction of a specified pre-condition that is contained in the particular event handler's event listener. Pre-conditions are described further below.
Usually, after the list of event handlers to be invoked has been completely generated, the event handlers in the list are invoked, one at a time, according to the order in which those event handlers occur in the list. However, the placement of a particular event handler within the list does not necessarily guarantee that the particular event handler actually will be invoked, or that the particular event handler will be invoked according to its initial order in the list; event handlers may be removed from the list and/or reordered within the list. Circumstances under which this might occur are described further below.
When an event handler is invoked, a corresponding method or procedure of the event handler's event listener's corresponding programmatic mechanism is called and executed. For example, when the “Post-LinkIn” event handler of the “Category application” event listener is invoked, a “Post-LinkIn” method or procedure of the “oracle.cm.category” programmatic mechanism is called and executed. For another example, when the “Post-LinkIn”event handler of the “Check quota” event listener is invoked, a “Post-LinkIn” method or procedure of the “oracle.ifs.category” programmatic mechanism is invoked. For yet another example, when the “Post-Update” event handler of the “Category application” event listener is invoked, a “Post-Update” method or procedure of the “oracle.cm.category” programmatic mechanism is called and executed. Each such method or procedure may perform customized, user-specified actions when invoked.
As is described above, each event handler corresponds to a file system event type. In one embodiment, the following file system event types are among those recognized: render, create, delete, update, lock, unlock, link in, link to, unlink in, unlink from, check in, check out, uncheck out, version control, inconsistent update, and open.
In the resource configuration shown above, both event listeners contain event handlers that correspond to the “link in”, “unlink in”, and “update” file system event types. Event handlers for a particular file system event type may be prefaced by “pre-” or “post-” prefixes. The “pre-” and “post-” prefixes are discussed further below.
A file system event of the “render” file system event type occurs when the contents of a node are dynamically generated.
A file system event of the “create” file system event type occurs when a node is created in the file hierarchy. Conversely, a file system event of the “delete” file system event type occurs when a node is deleted from the file hierarchy.
A file system event of the “lock” file system event type occurs when a node is placed in a state in which one or more entities are prevented from reading from and/or writing to a node. Conversely, a file system event of the “unlock” file system event type occurs when a node that had been placed in such a state is placed in a state in which the entities that were prevented from reading from and/or writing to the node are allowed to read from and/or write to the node.
A file system event of the “link in” file system event type occurs when a symbolic link is created in the file hierarchy. Conversely, a file system event of the “unlink in” file system event type occurs when a symbolic link is removed from the file hierarchy. A symbolic link is a pointer or reference to a node. A symbolic link may occur at a different location in the file hierarchy than the node and may have a different name than the node. For example, referring to FIG. 1, a symbolic link created as a child of directory 120 may refer to document 122. For another example, a symbolic link created as a child of directory 126 may refer to directory 116. Accessing such a symbolic link is equivalent to accessing the target node to which the symbolic link refers. If a symbolic link to document 122 was created as a child of directory 120, then document 122 would appear to be a child of directory 120 as well as a child of directory 124. If a symbolic link to directory 116 was created as a child of directory 126, then directory 116 would appear to be a child of directory 126 as well as a child of directory 114.
The creation and removal of symbolic links in and from the file hierarchy constitute file system events that are distinct from the association and disassociation of such symbolic link with and from target nodes in the file hierarchy. Thus, a file system event of the “link to” file system event type occurs when an existing, already created, symbolic link is associated with a target node in the file hierarchy. Conversely, a file system event of the “unlink to” file system event type occurs when an existing symbolic link is disassociated from a node with which the symbolic link had been associated. Because a user might want different actions to be performed upon occurrences of each of the “link in,” “link to,” “unlink in,” and “unlink to” file system event types, these file system event types are distinguished and separated accordingly, even though a “link to” type file system event typically accompanies a “link in” type file system event, and an “unlink to” type file system event typically accompanies an “unlink in” type file system event.
A file system event of the “check out” file system event type occurs when an entity causes a modifiable copy of an unchangeable version-controlled node to be created while preserving the original node in its unchangeable state. Conversely, a file system event of the “check in” file system event type occurs when an entity causes such a copy (with some modification) to become a new unchangeable version-controlled node in the file hierarchy—another “version” of the node that is accessible to other entities after being “checked in.” Alternatively, an “uncheck out” file system event type occurs when such a copy is disposed of without ever being “checked in.”
A file system event of the “version control” file system event type occurs when a node is placed under version control and given a version-controlled status, so that the node becomes an unchangeable version-controlled node from which modifiable copies may be made as described above. Some nodes may be under version control, while other nodes might not be.
In some file systems, nodes may be updated transactionally, so that incremental changes made to the node do not become permanent unless and until all of the incremental changes that belong to a transaction have been completed and committed—if any of the incremental changes of a transaction fails, then none of the transaction's changes are made permanent. A file system event of the “inconsistent update” file system event type occurs when such an incremental update is performed, even if the transaction to which the incremental update belongs has not yet been committed.
A file system event of the “open” file system event type occurs when an object handle or buffer for a node is established so that the node can be read from and/or written to via the object handle or buffer. Thus, a file system event of the “open” file system event type may occur prior to the node actually being read from or written to.
Pre- and Post-Event Handler Prefixes
As is described above, each event handler may be prefixed by “pre-” or “post-” prefix. In one embodiment, such prefixes affect the programmatic method or procedure to which an event handler corresponds, and also the timing of the calling and execution of the programmatic method or procedure relative to a file system event's occurrence. For example, a particular programmatic mechanism may contain one programmatic method or procedure for the “pre-update” event handler and another programmatic method or procedure for the “post-update” event handler. However, both the “pre-update” event handler and the “post-update” event handler correspond to the “update” file system event type.
As is described above, when a file system event is going to occur relative to a node in a file hierarchy, a list of event handlers to be invoked is been generated. According to one embodiment, those of the list's event handlers that are prefixed by “pre-” are invoked before the actual event occurs. After the file system event occurs, then those of the list's event handlers that are prefixed by “post-” are invoked.
For example, based on the example resource configuration shown above, in response to detecting that a node was going to be updated, the “post-update” method or procedure of the “oracle.cm.category” programmatic mechanism would be called and executed after the node was updated, and then the “post-update” method or procedure of the “oracle.ifs.category” programmatic mechanism would be called and executed. Alternatively, if the event handlers had been prefixed by “pre-” instead of “post-”, then the “pre-update” methods or procedures of both the “oracle.cm.category” and the “oracle.ifs.category” programmatic mechanisms would have been called and executed before the node was updated.
As is discussed above, in one embodiment, the addition of a particular event handler to the list of event handlers that are to be invoked is subject to the satisfaction of a specified pre-condition that is contained in the particular event handler's event listener. In one embodiment, before an event handler is added to the list of event handlers to be invoked, as described above, it is determined whether that event handler's event listener's pre-condition is satisfied. If the pre-condition is not satisfied, then the event handler is not added to the list.
In the example resource configuration shown above, the “Category application” and “Check quota” event listeners both contain pre-conditions, which are bounded by the “<pre-condition>” and “</pre-condition>” opening and closing tags. In the above example, both pre-conditions contain “existsNode” elements. Each “existsNode” element contains an expression that indicates a node or node type. In the above example, the nodes and node types are indicated via an XPath expression. When a pre-condition contains an “existsNode” element, it is determined whether the node or node type indicated within the “existsNode” element exists at the specified location in the file hierarchy. The pre-condition is satisfied only if the node or node type exists at the specified location. This is just one example of many different possible pre-conditions; other pre-conditions may contain expressions that do not involve the existence of a node or node type.
Event Handlers Altering the Invocation of Event Handlers
As is discussed above, the placement of a particular event handler within the list does not necessarily guarantee that the particular event handler actually will be invoked, or that the particular event handler will be invoked according to its initial order in the list. In one embodiment, when a file system event is going to occur relative to a node in a file hierarchy, an “event object” is created for that file system event. The event object contains the ordered list of event handlers that are to be invoked, as described above. The event object also comprises an interface of invocable methods or procedures that allow the list contained within the event object to be retrieved and altered.
In one embodiment, when the next event handler in the list is invoked, the event object is passed as a parameter to the event handler's corresponding programmatic method or procedure. The programmatic method or procedure may use the event object's interface to read the list and/or modify the list in accordance with user-specified logic within the programmatic method or procedure. For example, the programmatic method or procedure may re-order the event handlers that remain in the list. For another example, the programmatic method or procedure may remove one or more remaining event handlers from the list. Thus, event handlers may be removed from and/or reordered within the list by preceding event handlers regardless of the list's original ordering and composition.
When the programmatic method or procedure has finished executing, it returns the event object, which may contain a modified list of event handlers to be invoked. The next event handler in the list, if any, is then invoked.
FIG. 4 is a block diagram showing a database architecture that may be used to implement an embodiment of the present invention. The architecture comprises a user interface 410, a database server 412, and a database 414. Database server 412 interacts with the user via user interface 410, and accesses and maintains database 414 in accordance with the user input. Database server 412 may also interact with other systems (not shown).
Example Technique for Performing an Action in Response to a File System Event
FIGS. 5A-C show a flow diagram that illustrates a technique 500, according to an embodiment of the invention, for performing an action in response to a file system event. Database server 412 may perform technique 500, for example. Prior to the performance of technique 500, associations between resource configurations and nodes in a file system hierarchy may be established. Actions that are performed by event handlers that are contained in a resource configuration are considered to be associated with the same node with which the resource configuration is associated. Pre-conditions that are contained in an event listener are considered to be associated with the actions that are performed by event handlers that are contained in the event listener.
Referring first to FIG. 5A, in block 502, a file system event that is going to occur relative to a node within the file system is detected. In block 504, it is determined whether any more event listeners that are contained in a resource configuration that is associated with the entire file system contain an event handler that corresponds to the file system event. If so, then control passes to block 506. Otherwise, control passes to block 510 of FIG. 5B.
In block 506, it is determined whether the next such event listener's pre-condition is satisfied. If so, then control passes to block 508. Otherwise, control passes back to block 504.
In block 508, the event listener's event handler that corresponds to the file system event is added to the list of event handlers that are to be invoked. Control passes back to block 504.
Referring now to FIG. 5B, in block 510, it is determined whether any more event listeners that are contained in a resource configuration that is associated with the node contain an event handler that corresponds to the file system event. If so, then control passes to block 512. Otherwise, control passes to block 516.
In block 512, it is determined whether the next such event listener's pre-condition is satisfied. If so, then control passes to block 514. Otherwise, control passes back to block 510.
In block 514, the event listener's event handler that corresponds to the file system event is added to the list of event handlers that are to be invoked. Control passes back to block 510.
In block 516, an event object that contains the list of event handlers that are to be invoked is created.
Referring now to FIG. 5C, in block 518, prior to the occurrence of the file system event, it is determined whether any more event handlers that are prefaced by “pre-” are contained in the event object's list of event handlers to be invoked. If so, then control passes to block 520. Otherwise, control passes to block 524.
In block 520, the event object is passed as a parameter in a call to a programmatic method or procedure that corresponds to the next such event handler in the list. The programmatic method or procedure called is a programmatic method or procedure of the programmatic mechanism that corresponds to the event handler's event listener. The programmatic method or procedure may perform one or more user-specified actions. Such actions may include modifying the event object's list of event handlers to be invoked.
In block 522, the event object is received from the programmatic method or procedure. Control passes back to block 518.
In block 524, the file system event is allowed to occur.
In block 526, after the occurrence of the file system event, it is determined whether any more event handlers that are prefaced by “post-” are contained in the event object's list of event handlers to be invoked. If so, then control passes to block 528. Otherwise, the execution of technique 500 ends.
In block 528, the event object is passed as a parameter in a call to a programmatic method or procedure that corresponds to the next such event handler in the list. The programmatic method or procedure called is a programmatic method or procedure of the programmatic mechanism that corresponds to the event handler's event listener. The programmatic method or procedure may perform one or more user-specified actions. Such actions may include modifying the event object's list of event handlers to be invoked.
In block 530, the event object is received from the programmatic method or procedure. Control passes back to block 526.
US2001/0504042 Title not available
US5210686 Oct 19, 1990 May 11, 1993 International Business Machines Corporation Multilevel bill of material processing
US5222242 Sep 28, 1990 Jun 22, 1993 International Business Machines Corp. System for locating a node containing a requested resource and for selectively verifying the presence of the resource at the node
US5313629 Oct 23, 1989 May 17, 1994 International Business Machines Corporation Unit of work for preserving data integrity of a data-base by creating in memory a copy of all objects which are to be processed together
US5327556 May 11, 1993 Jul 5, 1994 International Business Machines Corporation Fast intersystem page transfer in a data sharing environment with record locking
US5410691 Dec 28, 1993 Apr 25, 1995 Next Computer, Inc. Method and apparatus for providing a network configuration database
US5467471 Mar 10, 1993 Nov 14, 1995 Bader; David A. Maintaining databases by means of hierarchical genealogical table
US5499358 Dec 10, 1993 Mar 12, 1996 Novell, Inc. Method for storing a database in extended attributes of a file system
US5524240 Oct 17, 1994 Jun 4, 1996 Panasonic Technologies, Inc. Method and apparatus for storage and retrieval of handwritten information
US5530849 Aug 16, 1993 Jun 25, 1996 Cornell Research Foundation, Inc. Method of reading dynamic, hierarchical file system directories
US5680614 May 20, 1993 Oct 21, 1997 Nec Corporation Relational database management system
US5729689 Apr 25, 1995 Mar 17, 1998 Microsoft Corporation Network naming services proxy agent
US5819275 Jun 7, 1995 Oct 6, 1998 Trusted Information Systems, Inc. System and method for superimposing attributes on hierarchically organized file systems
US5917492 Mar 31, 1997 Jun 29, 1999 International Business Machines Corporation Method and system for displaying an expandable tree structure in a data processing system graphical user interface
US5921582 May 15, 1998 Jul 13, 1999 Gusack; Mark David Indexing system, record structure, and linking methodology for paper-based and electronic-based informational assemblies
US5924088 Feb 28, 1997 Jul 13, 1999 Oracle Corporation Index selection for an index access path
US5956506 Apr 22, 1997 Sep 21, 1999 International Business Machines Corporation System and method for functionally enhancing procedural software using objects
US6055527 May 8, 1998 Apr 25, 2000 Network Associates, Inc. System, method and computer program product for superimposing attributes on hierarchically organized file systems
US6122645 Jan 5, 1998 Sep 19, 2000 Lucent Technologies, Inc. System and method for physically versioning data in a main memory database
US6128610 Aug 25, 1998 Oct 3, 2000 Oracle Corporation Index with entries that store the key of a row and all non-key values of the row
US6182121 Aug 4, 1998 Jan 30, 2001 Enfish, Inc. Method and apparatus for a physical storage architecture having an improved information storage and retrieval system for a shared file environment
US6192373 May 15, 1998 Feb 20, 2001 International Business Machines Corp. Managing directory listings in a relational database
US6208993 Jul 22, 1999 Mar 27, 2001 Ori Software Development Ltd. Method for organizing directories
US6332200 Oct 29, 1998 Dec 18, 2001 International Business Machines Corporation Capturing and identifying a complete and consistent set of checkpoint files
US6381607 Jun 19, 1999 Apr 30, 2002 Kent Ridge Digital Labs System of organizing catalog data for searching and retrieval
US6487469 Nov 10, 1999 Nov 26, 2002 Texas Instruments Incorporated System and method for integrating schedule and design environments
US6487552 Oct 5, 1998 Nov 26, 2002 Oracle Corporation Database fine-grained access control
US6493742 Dec 13, 1999 Dec 10, 2002 Weddingchannel.Com, Inc. System and method for providing internet accessible registries
US6587873 Jan 26, 2000 Jul 1, 2003 Viaclix, Inc. System server for channel-based internet network
US6604100 Feb 8, 2001 Aug 5, 2003 At&T Corp. Method for converting relational data into a structured document
US6725212 Aug 31, 2001 Apr 20, 2004 International Business Machines Corporation Platform-independent method and system for graphically presenting the evaluation of a query in a database management system
US6782380 Apr 14, 2000 Aug 24, 2004 David Victor Thede Method and system for indexing and searching contents of extensible mark-up language (XML) documents
US6889223 Mar 28, 2002 May 3, 2005 Kabushiki Kaisha Toshiba Apparatus, method, and program for retrieving structured documents
US6965894 Mar 22, 2002 Nov 15, 2005 International Business Machines Corporation Efficient implementation of an index structure for multi-column bi-directional searches
US6970975 Nov 15, 2002 Nov 29, 2005 Exanet Co. Method for efficient caching and enumerating objects in distributed storage systems
US7117216 Oct 19, 2001 Oct 3, 2006 Sun Microsystems, Inc. Method and apparatus for runtime merging of hierarchical trees
US7171407 Oct 3, 2002 Jan 30, 2007 International Business Machines Corporation Method for streaming XPath processing with forward and backward axes
US20020056025 Mar 1, 2001 May 9, 2002 Qiu Chaoxin C. Systems and methods for management of memory
US20020095421 Dec 13, 2000 Jul 18, 2002 Koskas Elie Ouzi Methods of organizing data and processing queries in a database system, and database system and software product for implementing such methods
US20020103829 Jan 30, 2001 Aug 1, 2002 International Business Machines Corporation Method, system, program, and data structures for managing structured documents in a database
US20020120858 Nov 30, 1998 Aug 29, 2002 Jack Edward Porter Method and apparatus for document management utilizing a messaging system
US20020138617 Sep 5, 2001 Sep 26, 2002 Jacob Christfort Providing content from multiple services
US20020184401 Oct 22, 2001 Dec 5, 2002 Kadel Richard William Extensible information system
US20030033285 Sep 27, 2002 Feb 13, 2003 Neema Jalali Mechanism to efficiently index structured data that provides hierarchical access in a relational database system
US20030065659 Sep 27, 2002 Apr 3, 2003 Oracle Corporation Providing a consistent hierarchical abstraction of relational data
US20030084056 Oct 11, 2002 May 1, 2003 Deanna Robert System for development, management and operation of distributed clients and servers
US20030131051 * Jan 10, 2002 Jul 10, 2003 International Business Machines Corporation Method, apparatus, and program for distributing a document object model in a web server cluster
US20030167456 Apr 13, 2001 Sep 4, 2003 Vinay Sabharwal Architecture for building scalable object oriented web database applications
US20030195865 May 30, 2003 Oct 16, 2003 Long David J. Transaction-aware caching for access control metadata
US20030200197 May 30, 2003 Oct 23, 2003 Oracle International Corporation Transaction-aware caching for document metadata
US20030212662 May 5, 2003 Nov 13, 2003 Samsung Electronics Co., Ltd. Extended markup language (XML) indexing method for processing regular path expression queries in a relational database and a data structure thereof
US20030233618 Jun 16, 2003 Dec 18, 2003 Canon Kabushiki Kaisha Indexing and querying of structured documents
US20040083222 May 2, 2003 Apr 29, 2004 Robert Pecherer Method of recursive objects for representing hierarchies in relational database systems
US20040103282 Apr 17, 2003 May 27, 2004 Robert Meier 802.11 Using a compressed reassociation exchange to facilitate fast handoff
US20040176958 Feb 4, 2002 Sep 9, 2004 Jukka-Pekka Salmenkaita System and method for multimodal short-cuts to digital sevices
US20040221226 Apr 30, 2003 Nov 4, 2004 Oracle International Corporation Method and mechanism for processing queries for XML documents using an index
US20040225680 May 8, 2003 Nov 11, 2004 Kim Cameron Declarative rules for metadirectory
US20050114314 Nov 26, 2003 May 26, 2005 International Business Machines Corporation Index structure for supporting structural XML queries
US20050160108 Jan 16, 2004 Jul 21, 2005 Charlet Kyle J. Apparatus, system, and method for passing data between an extensible markup language document and a hierarchical database
US20050228786 Sep 16, 2004 Oct 13, 2005 Ravi Murthy Index maintenance for operations involving indexed XML data
US20050228818 Mar 18, 2005 Oct 13, 2005 Ravi Murthy Method and system for flexible sectioning of XML data in a database system
US20050278354 Jun 4, 2004 Dec 15, 2005 Vinay Gupta Dynamic hierarchical data structure tree building and state propagation using common information model
US20050289138 Jun 25, 2004 Dec 29, 2005 Cheng Alex T Aggregate indexing of structured and unstructured marked-up content
EP856803A2 Title not available
GB2409078A Title not available
WO2000049533A2 Feb 17, 2000 Aug 24, 2000 Oracle Corporation Hierarchical indexing for accessing hierarchically organized information in a relational system
WO2001042881A2 Dec 6, 2000 Jun 14, 2001 B-Bop Associates, Inc. System and method for the storage, indexing and retrieval of xml documents using relational databases
WO2001059602A1 Feb 12, 2001 Aug 16, 2001 Acta Technologies, Inc. Nested relational data model
WO2001061566A1 Feb 16, 2001 Aug 23, 2001 Verizon Laboratories Inc. System and method for automatic loading of an xml document defined by a document-type definition into a relational database including the generation of a relational schema therefor
WO2003027908A2 Sep 27, 2002 Apr 3, 2003 Oracle International Corporation Providing a consistent hierarchical abstraction of relational data
1 "Notice of Allowance and Fee Due" received in U.S. Appl. No. 10/944,170 dated Apr. 7, 2008 (8 pages).
2 "Power Schemas with Styles Studio," Whitepaper published by Sonic Software Corporation, Jan. 2004.
3 Ali-Khalifa, S. et al., "Structural Joins: A Primitive for Efficient XML Query Pattern Matching," Feb. 26-Mar. 1, 2002, Data Engineering, 2002, Proceedings, 18th International Conference, pp. 141-152.
4 Amended Claims, EP App. 00952215.2 (26 pages).
5 Bouret, R. et al, "A Generic Load Extract Utility for Data Transfer Between XML Documents and Relational Databases," Proc. Second International Workshop on Advanced Issues of E-Commerce and Web-Based Information Systems, IEEE Computing Society, Jun. 8-9, 2000, pp. 134-143.
6 Brage, D. et al., "A Graphical Environment to Query XML Data with Query," Proceedings of the Fourth International Conference on Web Information Systems Engineering (WISE '03), 2003, IEEE, 10 pages.
7 Canadian Office Action received in Application No. 2,646,776 dated Dec. 23, 2009 (4 pages).
8 Chae, Mi-Ok, et al., "Design and Implementation of an Object-Oriented Multimedia DBMS Tightly Coupled with Information Retrieval Functions," Proc. 17th IASTED International Conference on Applied Informatics, Feb. 15-18, 1999, abstract.
9 Chakraborty, K., "The XML Garbage Collector," The Source for Developers, Sun Developer Network Site XP-002297849, Mar. 2002.
10 Chen, Ruey-Shun et al., "Developing an XML framework for metadata system," Trinity College Dublin, Proc. of the 1st International Sympo on Information and Communication, pp. 267-272.
11 Cheng, J. et al., "IBM DB2 XML Extender," IEEE, ICDE '00 Conference, San Diego, Feb. 2000, 128 pages.
12 Claims, European patent application 05732473.3-1225 (3 pages).
13 Claims, European patent application 2005800186273.9 (3 pages).
14 Claims, Foreign Application No. 200580018627.9 (3 pages).
15 Cooper, B. et al., "A Fast Index for Semistructured Data," Proceeding of the International Conference on Very Large Databases, 2001, XP-002303292 (pp. 341-350).
16 Cormen et al., "Introduction to Algorithms," MIT Press, 2001, 2nd edition (4 pages).
17 Current Claims in PCT/US03/355551, pp. 20-23.
18 Current Claims of Application No. 2,646,776, Dec. 2009 (3 pages).
19 Current Claims, PCT/US02/31168, EP App. No. 02799692.5 (8 pages).
20 Current Claims, PCT/US2005/011763 (4 pages).
21 Douglas et al., "Elephant: The File System That Never Forgets," in Proceedings of the IEEE Workshop on Hopt Topics in Operating Systems (HotOS VII), Mar. 1999 (6 pages).
22 European Patent Office, "Communication pursuant to Article 94(3) EPC," European patent application 05732473.3-1225, dated Feb. 4, 2008 (7 pages).
23 European Patent Office, "Communication Pursuant to Article 96(2) EPC," App. No. 00952215.2 dated Oct. 5, 2006, (7 pages).
24 European Patent Office, "Communication Pursuant to Article 96(2) EPC," EP Application No. 02799692.5, dated Jan. 18, 2006 (5 pages).
25 Giradot et al., "Milau: an encoding format for efficient representation and exchange of XML over the Web," IBM Almaden Research Center (24 pages).
26 IBM, "A method for faster searches of external file properties using negative caching of directory relationships, " IBM Corporation, IBM Technical Disclosure Bulletin, dated Jan. 1, 2001 (2 pages).
27 International Searching Authority, "Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration," PCT/US2005,011763, dated Aug. 6, 2005 (12 pages).
28 Jajodia, S. et al., "Toward a Multilevel Secure Relational Data Model," ACM, 1991, 8393 SIGMOD Record (Jan. 20, 1991) No. 2, New York, US, XP 000364619, pp. 50-59.
29 Japanese Patent Office, "Questioning (Office Action)" with "Pending Claims" attached, Foreign Application No. 600202/2000.
30 Jurgens, M. et al., "PISA: Performance Models for Index Structures with and without Aggregated Data," German Research Society, 1999 (7 pages).
31 Mackenzie et al., "Finding Files" FindUtils, Version 4.1.2, Source Code, GNU.org. Nov. 1997, source files, code.C,. (22 pages).
32 Manolescu, D., Review of "Metadata solutions: using metamodels, repositories, XML, and enterprise portals to generate information on demand by Adrienne Tannebaum," Mar. 2003, ACM Press, vol. 28, Issue 2, p. 38.
33 McHugh, J. et al., "Indexing Semistructural Data," Stanford Science Department, 1998, XP-002248313 (pp. 1-21).
34 McHugh, J. et al., "Query Optimization for XML," XP-002333353, Proceedings of the 25th VLDB Conference (1999) pp. 315-326.
35 Noser, H. et al., "Dynamic D3 Visualization of Database-Defined Tree Structures on the WWW by Using Rewriting Systems," 2000, IEEE, XP-002262516, pp. 247-254.
36 Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration received from International application No. PCT/US205/011762.
37 Oracle, "Oracle iFS (Internet File System)," Mar. 1999, XP-002204710, 3 pages.
38 Pal, S. et al., "Indexing XML Data Stored in a Relational Database," Proceedings of the 30th VLDB Conference, 2004 (12 pages).
39 Rao, H. et al., "An Overview of the Internet File System," 1997, IEEE, XP-002204711, pp. 474-477.
40 Ricardo, C., "Database Systems: Principles, Design & Implementation," 1990, MacMillian Publishing Co., pp. 357-361, 379-380.
41 State Intellectual Property Office of P.R.C., "Notification of the First Office Action," Foreign Application No. 200580018627.9, mailed Oct. 12, 2007 (9 pages).
42 U.S. Appl. No. 11/014,442, filed Dec. 15, 2004, Decision on Appeal, Jul. 25, 2011.
43 U.S. Appl. No. 11/014,442, filed Dec. 15, 2004, Notice of Allowance, Oct. 27, 2011.
44 U.S. Appl. No. 12/122,517, filed May 16, 2008, Notice of Allowance, Jul. 14, 2011.
45 Vorthmann, S. et al., "Beyond Schemas, Schema Adjuncts and the Outside World," Markup Languages, Online!, vol. 2, No. 3, Jun. 2000, pp. 1-8.
46 Written Opinion, Application No. PCT/US03/35551 (8 pages).
47 Yoshikawa, M. et al., "XRel: A Path-Based Approach to Storage and Retrieval of XML Documents Using Relational Databases," XP-001143686, ACM Transactions on Internet Technology (2001), pp. 110-141.
U.S. Classification 707/609, 707/770, 707/760
Cooperative Classification G06F17/30067, G06F9/542
European Classification G06F9/54B, G06F17/30F