Humans tend to organize information in categories. The categories in which information is organized are themselves typically organized relative to each other in some form of hierarchy. For example, an individual animal belongs to a species, the species belongs to a genus, the genus belongs to a family, the family belongs to an order, and the order belongs to a class.
With the advent of computer systems, techniques for storing electronic information have been developed that largely reflected this human desire for hierarchical organization. Conventional operating systems, for example, provide file systems that use hierarchy-based organization principles. Specifically, a typical operating system file system (“OS file system”) has folders arranged in a hierarchy, and documents stored in the folders. Ideally, the hierarchical relationships between the folders reflect some intuitive relationship between the meanings that have been assigned to the folders. Similarly, it is ideal for each document to be stored in a folder based on some intuitive relationship between the contents of the document and the meaning assigned to the folder in which the document is stored.
Recently, techniques have been developed to use a relational database to store files that have traditionally been stored in OS file systems. By storing the files in a relational database, the files may be accessed by issuing database commands to a database server. In many circumstances, retrieving and manipulating files by issuing database commands can be much more efficient than by issuing file system commands due to the enhanced functionality of database servers. One system in which a relational database is used as the back end of a file system is described in U.S. patent application Ser. No. 09/571,508, entitled “Multi-Model Access to Data”, filed on May 15, 2000 by Eric Sedlar, the entire contents of which are incorporated herein by this reference. In the Sedlar system, the files are accessible both (1) by making calls to conventional file system APIs, and (2) by issuing queries to the database server.
A transaction is an “all or nothing” unit of work. Changes made by operations that belong to a transaction are not made permanent until all changes in the transaction are successfully made and the transaction commits. If any operation within a transaction fails, then all changes made by the transaction are undone. The removal of changes made by a transaction is referred to as a “rollback” operation.
When an OS file system is implemented using a relational database system, a series of file system operations may be performed as a transaction within the database system. Techniques for performing file system operations as a transaction are described in U.S. patent application Ser. No. 09/571,496, which issued as U.S. Pat. No. 6,922,708 on Jul. 26, 2005, entitled “File System that Supports Transactions”, filed on May 15, 2000, by Eric Sedlar, the entire contents of which are incorporated herein by this reference.
The ability to perform file system operations within an all-or-nothing transaction is extremely helpful in certain situations. For example, assume that a certain program requires ten files to run. Assume further that all of those ten files must reside in the same folder for the program to run correctly, that the files currently reside in a first folder and that a user wants to move the files to a second folder. If all ten of the files cannot be moved to the second folder, then it would be desirable for none of the ten files to be moved so that the program can still be run from the first folder.
Unfortunately, there are many situations in which the all-or-nothing nature of transactions is too simplistic for the behavior that is desired of the file system. For example, assume that the file system has been configured to send an email to the owner of a file and to the system administrator in response to the file being copied. A user may want to be able to copy the files in a folder, and have the system operate according to the following rules:
RULE 1: If any folder contains other folders, and the entire contents of the folder are being copied, then the entire contents of the other folders should be copied.
RULE 2: If all of the documents in a folder cannot be copied, then none of the documents should be copied.
RULE 3: If all of the documents in a folder can be copied, then they should be copied regardless of whether the contents in any other folders can be copied.
RULE 4: If all of the documents in a folder can be copied, then they should be copied regardless of whether any email is sent.
RULE 5: For any given file, if email cannot be sent to both the owner and the system administrator, then no email should be sent.
To accomplish rules 1, 2 and 5, the user may cause the file copy operations and the email transmission operations to be performed as part of a single transaction. However, this could result in violation of rules 3 and 4. For example, if the sending of email is performed as part of the same transaction as the copying of a document, then the failure of an email will necessarily cause a failure of the copy operation.
Based on the foregoing, it is clearly desirable to provide techniques that allow the use of more sophisticated policies with respect to the transactional relationships between file system operations, and operations triggered by file system operations.