US20060136460A1 - Managed file system filter model and architecture - Google Patents
Managed file system filter model and architecture Download PDFInfo
- Publication number
- US20060136460A1 US20060136460A1 US11/344,258 US34425806A US2006136460A1 US 20060136460 A1 US20060136460 A1 US 20060136460A1 US 34425806 A US34425806 A US 34425806A US 2006136460 A1 US2006136460 A1 US 2006136460A1
- Authority
- US
- United States
- Prior art keywords
- filter
- callback
- request
- file
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/1734—Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99934—Query formulation, input preparation, or translation
Definitions
- the invention relates generally to computer systems, and more particularly to file systems and file systems filters.
- filter drivers are kernel-mode drivers that enhance the underlying file system by performing various file-related computing tasks that users desire, including tasks such as passing file system I/O (requests and data) through anti-virus software, file system quota providers, file replicators and encryption/compression products.
- antivirus products provide a filter that watches I/O to and from certain file types (.exe, .doc, and the like) looking for virus signatures, while file replication products perform file system-level mirroring.
- Other types of file system filter drivers are directed to system restoration (which backs up system files when changes are about to be made so that the user can return to the original state), disk quota enforcement, backup of open files, undeletion of deleted files, encryption of files, and so forth.
- system restoration which backs up system files when changes are about to be made so that the user can return to the original state
- disk quota enforcement backup of open files
- undeletion of deleted files encryption of files, and so forth.
- the existing file system filter model in contemporary Windows®-based operating systems leverages the inherent I/O model, which is a packet-based approach.
- file system filters load as regular drivers in a stack and attach to the underlying file system's volume device objects.
- User I/O requests are converted by an I/O manager into I/O Request Packets (IRPs), which are sent to the driver stack and processed by the top driver, which may complete it, pass it down in a call to another driver towards the file system, which calls the next lower driver, and so on.
- IRPs I/O Request Packets
- each driver does whatever processing it is coded to perform on the IRP, and then explicitly passes down the IRP to the next lower driver (or file system if none are lower), or completes (or fails) the IRP and sends it back up the stack to the next higher driver (or the I/O manager if none are higher).
- Another problem is efficiency, as file system filters traditionally receive and process every operation that normally goes to a file system, even those in which they have no interest in. For example, an antivirus product can slow down a system as much as sixty percent, but not every I/O request received by an antivirus filter is one that the filter will do anything with, namely inspect any corresponding data for viruses. Redundancy is also a problem that leads to inefficiency and computing cost, as many filters do the same things in different ways, leading to unnecessary code.
- Interoperability between drivers is also a significant problem, as, for example, one driver may modify I/O in a way that the other driver does not anticipate and cannot properly deal with. Note that interoperability problems are one of the biggest drawbacks of the existing model, in part because filters have only a very coarse-grained control over attachment ordering to a file system.
- the present invention provides a model/architecture in which filter drivers are managed by a filter manager to receive callbacks for I/O requests in which the filter drivers have registered an interest.
- the model eliminates traditional, complex I/O passing by providing a managed callback model, in which IRPs, fast I/O paths, Fs Filter callbacks and so forth are translated by a filter manager into callbacks that provide callback data in an explicit, well-defined format into the filters.
- the filters manipulate the callback data as desired, and return a status in response to the callback, as described below. As one result, filters no longer have to deal with IRPs.
- a filter manager translates the I/O, whether an IRP, fast I/O, FS Filter callback or the like, into a uniform structure known as ‘callback data’.
- the filter manager may be placed into the legacy filter driver stack as if it is a legacy filter driver, so that it can receive and process IRPs.
- the filter manager then walks through a list of appropriately registered filter drivers to invoke a registered dispatch for the I/O.
- Filter drivers comprise may objects (or similar such components) that when instantiated register with a registration mechanism in the filter manager.
- the filter drivers only register for file system requests in which they may be interested in processing, by notifying the filter manager of the types of I/O requests in which it is interested (e.g., create, read, write, close and so forth).
- the model is more efficient than a stacked filter model, because filter drivers do not see I/O requests that they are not interested in, and thus have not registered for.
- filter drivers separately attach to volumes as filter driver instances, on a per-volume basis, and a filter driver may attach multiple instances to the same volume.
- Each filter driver instance is associated with an ‘altitude’ which indicates where in the callback order that driver is located. The altitude may be pre-defined, or derived from flags provide by the driver that indicate the type of processing the driver will perform on the callback data.
- the filter manager To efficiently track which filter drivers have registered for which types of callbacks and thereby efficiently callback the appropriate drivers in the proper order, the filter manager maintains per-volume, ordered lists, each list indexed by a type of operation for which filters have registered interest in receiving pre-callbacks and/or post-callbacks. The filter manager uses this list to callback the filters in the appropriate order, and each filter returns a status. Assuming success, following the last pre-callback, the filter manager reconverts the callback data to an IRP and sends the IRP to the file system.
- Post-callback essentially works in the opposite order, although a filter can indicate that it wants to be skipped over during the post-callbacks.
- I/O completion is handled by the filter manager in a manner that guarantees that the parameters seen by a filter instance in its pre-callback are the same in its post-callback.
- the filter manager maintains a completion node stack which it accesses to return the correct parameters in each post callback.
- the filter manager also provides a rich API set that provides functions which filters commonly need. For example, certain filters need to perform I/O of their own, and various functions are provided that facilitate such operations. Various functions also provide efficient context support with instances, volumes, files, stream handles, or streams keeping track of the context data for each filter in association with the appropriate object.
- the present invention provides notification support via a set of callbacks that setup notification for an entity, and simplifies the association of a per-filter context with that entity. Contexts may be set and/or reset any time. Still other functions enable communication between kernel mode filter drivers and user mode counterpart services and programs, while other functions provide naming support as described in U.S. patent application Ser. No. 10/187119, filed on Aug. 28, 2002.
- FIG. 1 is a block diagram generally representing a computer system into which the present invention may be incorporated;
- FIG. 3 is a block diagram generally representing instances of managed filters in accordance with an aspect of the present invention.
- FIG. 4 is a block diagram generally representing data structures used by a filter manager to selectively pass I/O to appropriately registered filters in accordance with an aspect of the present invention
- FIG. 5 is a representation of a stack of completion nodes for returning callback data to registered filter drivers in a post-callback operation in accordance with an aspect of the present invention
- FIG. 6 is a block diagram representing a tree for efficient determination of which instances have context data in accordance with an aspect of the present invention.
- the invention is operational with numerous other general purpose or special purpose computing system environments or configurations.
- Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
- the invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
- program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types.
- the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
- program modules may be located in both local and remote computer storage media including memory storage devices.
- such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
- ISA Industry Standard Architecture
- MCA Micro Channel Architecture
- EISA Enhanced ISA
- VESA Video Electronics Standards Association
- PCI Peripheral Component Interconnect
- the computer 110 typically includes a variety of computer-readable media.
- Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media.
- Computer-readable media may comprise computer storage media and communication media.
- Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data.
- Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 110 .
- Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
- modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
- communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
- the system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132 .
- ROM read only memory
- RAM random access memory
- BIOS basic input/output system
- RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120 .
- FIG. 1 illustrates operating system 134 , file system 135 , application programs 136 , other program modules 137 and program data 138 .
- the computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
- FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152 , and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media.
- removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
- the hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140
- magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150 .
- hard disk drive 141 is illustrated as storing operating system 144 , application programs 145 , other program modules 146 and program data 147 . Note that these components can either be the same as or different from operating system 134 , application programs 136 , other program modules 137 , and program data 138 . Operating system 144 , application programs 145 , other program modules 146 , and program data 147 are given different numbers herein to illustrate that, at a minimum, they are different copies.
- a user may enter commands and information into the computer 110 through input devices such as a tablet (electronic digitizer) 164 , a microphone 163 , a keyboard 162 and pointing device 161 , commonly referred to as mouse, trackball or touch pad.
- Other input devices may include a joystick, game pad, satellite dish, scanner, or the like.
- a monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190 .
- the monitor 191 may also be integrated with a touch-screen panel or the like. Note that the monitor and/or touch screen panel can be physically coupled to a housing in which the computing device 110 is incorporated, such as in a tablet-type personal computer. In addition, computers such as the computing device 110 may also include other peripheral output devices such as speakers 195 and printer 196 , which may be connected through an output peripheral interface 194 or the like.
- the computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180 .
- the remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110 , although only a memory storage device 181 has been illustrated in FIG. 1 .
- the logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173 , but may also include other networks.
- LAN local area network
- WAN wide area network
- Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
- the computer system 110 may comprise source machine from which data is being migrated, and the remote computer 180 may comprise the destination machine.
- source and destination machines need not be connected by a network or any other means, but instead, data may be migrated via any media capable of being written by the source platform and read by the destination platform or platforms.
- the computer 110 When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170 .
- the computer 110 When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173 , such as the Internet.
- the modem 172 which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism.
- program modules depicted relative to the computer 110 may be stored in the remote memory storage device.
- FIG. 1 illustrates remote application programs 185 as residing on memory device 181 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
- the present invention is generally directed towards a file system filter model and architecture that is intended to improve file system I/O handling by filters, including by facilitating the interoperability among various file system-related products.
- the model is generally described herein with reference to filter drivers that operate between the I/O manager and a base file system, which can be a local or remote file system, and not described with reference to other drivers, including filter drivers that operate between the file system and the storage driver or drivers (such as FtDisk or DMIO).
- legacy filter drivers are those that handle I/O request packets (IRPs) in the traditional manner, rather than by the new model, which uses callbacks to registered filter drivers as described below. As it is expected that legacy filter drivers will be phased out over time, filter drivers that comply with the new registration and callback model will be referred to herein simply as “filter drivers.”
- One of the primary aspects of the new filter model is directed to eliminating traditional, complex I/O passing from legacy filter to legacy filter through a stack model, and replace that model with a managed callback model, in which IRPs, fast I/O paths, memory manager callbacks and so forth are translated by a filter manager into callbacks that provide callback data in a defined format into the filters.
- the filters do not call other filters, or directly pass control to other filters, but rather manipulate the callback data as desired, and return a status in response to the callback, as described below. Since filters no longer have to deal with IRPs and the like, much of the I/O handling complexity is removed from the filters and built into a single filter manager, eliminating many of the problems caused by various filters.
- IRPs often contain implicit, complex information that legacy filter drivers have traditionally had difficulty in dealing with; the present invention eliminates this problem by having the filter manager deal with the implicit information, and pass only explicit context to the filters.
- the callback model further has the benefit of solving stack overflow and locking issues that arise due to chained IRP dispatches.
- FIG. 2 represents an example implementation 200 of the new model.
- One advantage of the implementation represented in FIG. 2 is that existing applications, operating system components and file systems need not be modified in any way to implement the new model.
- an application 202 will still continue to make file system requests (e.g., via function/method calls) through an API layer 204 to an I/O manager 206 .
- the I/O manager 206 generates an IRP or other type of I/O, and sends the I/O to the top of the (legacy) filter driver stack 208 .
- one of the components in the stack 208 is a filter manager 212 .
- the filter manager 212 translates the I/O, whether an IRP, fast I/O, FS Filter callback or the like into a uniform structure known as callback data.
- a suitable callback data structure is described below.
- the filter manager 212 then walks through a list of registered filter drivers (e.g., five such filter drivers 282 A - 282 E are shown in FIG. 2 , although there may be any practical number of such drivers), and for each filter driver, may invoke a registered dispatch for the I/O.
- filters do not receive and/or handle IRPs, but instead essentially instruct the filter manager 212 on what to do with the I/O request.
- legacy filter drivers 210 may still be supported in this implementation, such as by placing them at the top of the stack 210 . Note however that it is feasible to arrange them in some other order relative to other stack components. For example, since legacy filter drivers are arranged to handle IRPs, not callbacks, special management code may surround such a legacy filter to generate an IRP from callback data to pass to it and receive the (possibly modified) IRP from it and convert it back to a status response. In this manner, a legacy filter can be inserted and isolated within the callback model. In any event, legacy filters may still be used in the new model.
- the file system filter manager 212 is employed in the new model, and placed into the filter driver stack 208 as if it is a legacy filter driver, so that it can receive and process IRPs. Note that this allows the filter manager to simply work in an existing I/O system, however it can be appreciated that an equivalent model (e.g., without higher legacy filters) can be provided in which an updated I/O manager passes I/O data to a filter manager in something other than an IRP data structure. For example, when the I/O manager generates an IRP, the filter driver generates a callback data structure from the IRP, and thus it may be more efficient to have the I/O manager directly generate the callback data structure.
- an equivalent model e.g., without higher legacy filters
- filter drivers comprise objects or the like that when instantiated, typically during their driver initialization procedure, register with a registration mechanism in the filter manager 212 .
- the filter drivers typically will only register for file system requests in which they may be interested in processing.
- each filter driver notifies the filter manager for the types of I/O requests in which it is interested (e.g., create, read, write, close and so forth).
- an encryption filter driver may register for read and write IRPs, but not for others wherein data does not have to be encrypted or decrypted.
- a quota filter may be interested only in file creates and file writes.
- the model is more efficient than a stacked filter model, because filter drivers only see the I/O for which they have registered.
- the model of the present invention defines the concept of an “instance” of a filter driver (and also a volume context as described below). More particularly, filter drivers that wish to attach to a volume are notified via an instance setup notification when a new volume is mounted. A similar notification is provided for volumes that have already mounted before a filter driver is loaded. Filter drivers can then choose to attach to the volume via registration, described below, and if so, an instance object is used to represent the instance of the attachment. Filter drivers are similarly notified when a volume dismounts, namely through an instance detach notification. The present model also allows for filter drivers to dynamically detach from a mounted volume.
- a filter driver may be associated with an altitude which indicates where in the callback order that driver is located, such as generally described in U.S. patent application Ser. No. 09/768,098 entitled “Method and System for Deterministic Ordering of Software Modules.”
- filter drivers can attach multiple times to the same volume, creating an instance for each attachment, (although to do so, each instance for the same volume is necessarily at a different altitude, whether by an order number or by some override mechanism).
- FIG. 3 shows an example filter that has multiple instances.
- filter A e.g., a “filesystem activity monitoring” filter
- monitors file I/O and has two instances, filter A and filter A′.
- a file activity monitoring product is able to observe (via filter A) I/O going in to an intermediate (e.g., anti-virus) filter B, as well as observe (via filter A′) the I/O that eventually passes through that intermediate filter on its way towards the file system.
- the file activity monitoring product may include a user mode program (not separately shown) which both filter A and filter A′ report to, via messages as described below.
- per-volume filter driver instances may be associated with an altitude that determines where each instance is located for that volume.
- Altitudes may be pre-assigned to a given filter instance, such as in U.S. patent application Ser. No. 09/768,098, and/or a flag mechanism or the like (described below) may be used to derive an appropriate altitude for a filter.
- an antivirus filter should not be allowed to attach between an encryption filter and the base file system, since it needs to see the data as is, prior to encryption.
- Flags can indicate whether a filter inspects data (e.g., an antivirus filter), modifies data, (e.g., an encryption filter), and so forth, from which an altitude may be derived. In this manner, the callback order is not based on the order in which drivers are loaded, but rather on some predetermined, logical basis.
- filter drivers register two kinds of callbacks, namely pre-callbacks and post callbacks.
- the pre-callback is called on the I/O's way down, that is, towards the file system, while the post-callback is called during the completion of the I/O, on the way back up from the file system towards the I/O manager.
- the filter manager 212 maintains one or more per-volume data structures. For example, as represented in FIG. 4 , when a filter instance registers at a registration mechanism 402 (e.g., by calling a function) in the filter manager 212 , the registration mechanism determines, via an ordering mechanism 404 where in the pre-callback order the filter instance belongs.
- the ordering mechanism 404 may be based on a simple comparison of altitudes, or may include logic that evaluates flags to determine where the filter instance fits in. In any event, per-volume callback nodes are maintained, with the registration information therein.
- part of the information sent to the filter manager in registration comprises (e.g., in an array) a list of the file system requests for which a filter instance wants a pre-callback.
- This information is used to construct a per-volume ordered list 408 (e.g., volume c:) or 410 (e.g., volume d:) or the like by which a callback mechanism 412 in the filter manager 212 can efficiently determine the order for calling each instance. For example, as represented in FIG.
- the filter instances interested in read may be quickly obtained, e.g., filter instance A, filter instance B and filter instance A′ will be the pre-callback order, as represented in the example in FIG. 4 . Note that this is highly efficient, and also facilitates dynamic registration; at any time a new filter instance registers, the registration mechanism can rebuild the lists as appropriate.
- the pre-callback order is determined per type of file I/O request, although as described below, the status returned by each filter instance may impact the actual filter instances that receive callbacks, e.g., a filter can fail a callback.
- Post-callback works essentially in the opposite order, however as described below, one of the status values that a called instance can return in a pre-callback is success without a post callback, in which case the filter manager 212 will skip the post callback for that instance.
- the status values that a filter instance may return in response to a callback generally include success without callback, success with callback, pending, synchronize, complete, and disallow fast I/O.
- “FLT_PREOP_SUCCESS_NO_CALLBACK” continues processing the I/O pass through, as does the status “FLT_PREOP_SUCCESS_WITH_CALLBACK,” which further requests a completion callback when this I/O completes.
- a filter can also specify FLT_PREOP_PENDING, which holds the I/O until the filter later calls FltCompletePendedPreOperation( ).
- FLT_PREOP_SYNCHRONIZE waits for the I/O to complete, and calls post-callback in the original thread context.
- FLT_PREOP_COMPLETE completes the I/O with either a success or failure status code (which is generally analogous to an IoCompleteRequest in a legacy dispatch).
- FLT_PREOP_DISALLOW_FAST_IO is valid only for Fast I/O, and is generally equivalent to returning FALSE in a legacy dispatch.
- the managed filter driver model allows filter drivers to control the execution path of the I/O via the return status from their pre-callback routine. This allows filter drivers to request different ways for the I/O to be handled, including pended, completed, passed on to lower filters, request a post-callback, request a ‘synchronized’ post-callback and so forth.
- filter instances register for post-callbacks.
- a filter instance e.g., that previously returned a status of FLT_PREOP_SUCCESS_WITH_CALLBACK
- a filter can reissue an I/O during its post-operation processing via the FltReissueSynchronousIo( ) function call for reparse handlers.
- a FLT_POSTOP_UNDO_CREATE status is provided for filters that want to block file opens by failing the create request.
- I/O completion is handled by the filter manager 212 in a manner that guarantees that the parameters seen by a filter instance in its pre-callback are the same in its post-callback. Note that this is an improvement over the legacy stacked model in which filters often changed parameters, buffer pointers and so on, leading to numerous problems. In general, this is performed as represented in FIG. 5 , wherein the filter manager maintains a completion node for each instance, (that is, at least for those instances receiving callbacks).
- the filter manager takes a snapshot of the parameters before each pre-callback, stores the snapshot in the completion node, and pushes the completion node onto a stack 502 .
- the filter manager maintains an IRPCTRL header 504 , not seen by the filter driver, that tracks information including the device object, an IRP pointer, node information including the size of the completion nodes and its corresponding instance, and so forth.
- the filter manager essentially walks backwards, popping each completion node off of the stack 504 and putting the completion node data into the callback data 506 for that instance, thereby restoring its parameters.
- the stack can be copied to another stack with an added completion node if a filter instance registers dynamically before it is pre-called in the order; if registered after the pre-calling has already passed it in the pre-calling order for a given IRP, that instance would not be called back.
- the stack only needs to have a completion node pushed onto the stack when a filter instance is to receive a callback, and when a filter instance makes a change to the callback data, since otherwise the same completion node can be reused.
- a filter instance is responsible for setting a “dirtied” parameters flag when it modifies the data. Note that if it does not do so, its changes will be discarded and it will not have its changed data snapshotted, whereby any changes would not be seen by another driver.
- the filter manager 212 reconverts (marshals) the callback data into an IRP and returns the IRP up the stack towards the I/O manager 206 , through any higher legacy filters 210 .
- this managed filter model many of the drawbacks of the legacy model are eliminated or significantly reduced.
- the filter manager also provides a rich API set that provides functions which filters commonly need. For example, certain filters need to perform I/O of their own, e.g., an anti-virus filter may wish to read a file before it is opened.
- a filter driver wishes to initiate its own I/O operation, it first calls FltAllocateCallbackData( ). This function allocates and returns an FLT_CALLBACK_DATA structure, which the filter then populates with any relevant fields. Note that FltAllocateCallbackData is essentially the replacement for calling IoAllocateIrp( ) in the legacy system.
- the filter When the filter is ready to send the I/O request on to any remaining filters, legacy filters, and the base file system, it calls FltPerformSynchronousIo( ) or FltPerformAsynchronousIo( ) (analogous to IoCallDriver( )).
- FltPerformSynchronousIo( ) or FltPerformAsynchronousIo( ) analogous to IoCallDriver( )
- filter-initiated I/O is sent to the next attached filter for the given volume, bypassing any filters attached above the filter initiating the I/O. It is possible, however, to send I/O to any device in the system, as a hierarchical storage management (HSM) filter might need to do.
- HSM hierarchical storage management
- filters sometimes need to create a file
- the FltCreateFile( ) function is provided as a starting point for initiating I/O.
- This function returns a handle that can be used with existing operating system APIs that take file handles, and allows file create on other instances.
- the function supports share-access override.
- the filter manager ensures that any callbacks are only seen by filters below the requesting filter, including those dynamically inserted, which, as can be appreciated, avoids recursive callbacks.
- the filter manager creates a file with an instance hint, and uses this hint to identify the requesting filter. Note that mount point opens are an exception, as they need to go to top of the callback stack.
- FltReadFile( ) allows synchronous and asynchronous I/O, with filter-supplied callback that will be issued on I/O completion.
- FltWriteFile( ), FltSetInformationFile( ) and so forth have similar semantics.
- FltAllocateCallbackData( ) allows I/O to be customized, including FltPerformSynchronousIo( ), or FltPerformAsynchronousIo( ) which accepts an I/O completion callback.
- Context management is another example where filter manager-provided APIs are highly beneficial, as filters often need to associate a context structure with each stream handle, stream, instance and volume.
- filters use the contexts to store per handle/per stream/per file/per volume/per instance information that is looked up when a filter intercepts I/O. Any context or contexts that a filter has set on an entity will be passed to the filter when that filter requests it, e.g., via an API.
- the context lifetime is managed by the filter manager 212 , and filters will be called back when the context is deleted due to the appropriate object (such as stream/file/instance/volume) being deleted.
- the filter manager 212 provides efficient context support to store context data (e.g., pointers or the like) for each filter in the appropriate object, that is, for a stream handle, stream, file, instance or volume.
- context data e.g., pointers or the like
- the present invention provides context support, via a set of APIs that return context to an entity, and thus simplifies the association of a per-filter context with that entity. Contexts may be set and/or reset any time.
- the present invention also provides notification support for instances, via a set of callbacks that setup notification for an instance.
- the types of entities include instances, volumes (a local disk volume, or a remote network share), streams (for file systems that support multiple streams per file), stream handles (per-file objects), and files (e.g., all streams of a file).
- instances as described above, when a filter attaches to a volume, an instance is created, and, as also described above, there may be more than one instance of a given filter for a given volume, e.g., attached both above and below another filter on the same volume.
- Each instance can have a context associated, for example to point to a private log for that instance.
- a volume context can be shared among filter instances.
- the filter calls FltAllocateContext( ) specifying the type of context (stream handle, stream, file, instance or volume), the size of context and whether the context should be allocated from paged or non-paged pool memory.
- FltAllocateContext( ) specifying the type of context (stream handle, stream, file, instance or volume), the size of context and whether the context should be allocated from paged or non-paged pool memory.
- the filter associates the context with the object by calling the appropriate routine: FltSetStreamHandleContext( ), FltSetStreamContext( ), FltSetFileContext( ), FltSetInstanceContext( ) or FltSetVolumeContext( ).
- the filter manager 212 adds a tree (e.g. a splay tree) to the data structures associated with the file object. More particularly, the operating system facilitates the adding of arbitrary context to a stream, and the filter manager 212 uses this mechanism to add a stream control list 608 and a tree 610 to the FSRTL_ADVANCED_FCB_HEADER 612 , which essentially is pointed to by the file object 614 via its context 616 . Each node in the tree 610 represents a filter instance that has an associated context for this stream. Although not separately shown, there may be parallel trees, one for paged-pool memory and one for non-paged pool memory, as specified by the filter instance for different types of access that may be needed.
- a tree e.g. a splay tree
- each node in the tree is accessed by keys, including the file object as one key and the instance as another.
- the file object key is NULL.
- the appropriate node in the tree 610 can be quickly located for the filter driver instance 702 , and the appropriate context 704 (e.g., in the form of a context pointer) returned to the requesting filter driver instance 702 .
- the traversal is fast because there are not generally that many filter instances in a given configuration.
- a filter may receive a notification for an instance: typedef PVOID PFLT_CONTEXT; NTSTATUS (*PFLT_INSTANCE_SETUP_CALLBACK) ( IN CONST PFLT_RELATED_OBJECTS FltObjects, IN FLT_INSTANCE_SETUP_FLAGS Flags, IN DEVICE_TYPE VolumeDeviceType ); If context is needed for a particular instance, it can set it in this callback. The context is a PVOID, and the system will treat it as completely opaque, so a filter can use it to store a flags field, a counter, a pointer, or anything else it needs.
- a filter that provides a context structure for some entity will have its corresponding ContextCleanupCallback called.
- a filter does not need to keep track of which contexts it has allocated, as the system will take care of when cleanup should occur.
- the system calls the filter's ContextCleanupCallback.
- the filter is responsible to uninitialize the contents of the context and upon return the system will free the memory allocated by the filter's earlier FltAllocateContext( ) call. Cleanups are assumed to succeed; therefore there need not be a return value.
- the system also guarantees that the context cleanups routines will be called at an IRQL low enough that pool frees can be done safely.
- An instance context gets cleaned up when the filter is detached from the volume.
- a volume context gets cleaned up after the volume is dismounted, and after all files, streams, and stream handles for the volume are cleaned up. Due to memory manager, cache manager, and file system implementation details, the volume context may not be cleaned up for a relatively long time after the volume is dismounted.
- a file context gets cleaned up when the file system frees the memory associated with the file, which in a multiple-stream file system, will be after the last stream handle for the last stream for that file is freed. Note that because the operating system's memory manager and cache manager may still have references to one or more streams in the file, the file context may not be cleaned up for a relatively long time after the last user handle to the stream is closed. Similarly, a stream context gets cleaned up when the file system frees the memory associated with the stream, which will be after the last stream handle for that stream is freed. Again, because the operating system's memory manager and cache manager may still have references to one or more streams in the file, the stream context may not be cleaned up for a relatively long time after the last user handle to the stream is closed.
- a stream handle context gets cleaned up when the last reference to the stream handle is released. This may be as a result of the user handle being closed, or the last memory manager or cache manager reference being released.
- a context can be set for an object if the object does not currently have a context, or a context can be changed.
- a filter can clear a context using one of the following routines, as appropriate: FltDeleteContext( ), FltDeleteVolumeContext( ), FltDeleteInstanceContext( ), FltDeleteFileContext( ), FltDeleteStreamContext( ) and FltDeleteStreamHandleContext( ).
- a filter will want some basic information about an entity to decide if it is interested in it.
- this might be the file system, whether the volume is local or remote, whether it is on removable media, and so on.
- this may include the file's name, timestamps, size, extension, and so forth.
- the system may expose functions (e.g., FltGetFileInformation( ), FltGetVolumeInformation( )) to conveniently retrieve this information.
- the filter may also wish to call FltTagFile( ) to set a reparse point on a file.
- Yet another set of APIs provide by the architecture of the present invention, are directed towards facilitating communication between filter instances and user mode code. More particularly, many filters have a user-mode service counterpart that is typically the administrative component of the product, and filters need to communicate with the service.
- the present architecture may provide APIs for these products to use for both user-mode initiated as well as kernel-initiated communication.
- a library is available for those user-mode applications.
- the library exposes routines, including routines to load and unload filters, attach and detach filters to volumes, open communication channels to filters from user-mode and send/receive data from the filters, and query the system for information on the current status of the system. For example, a user mode program may query for which filters are currently loaded, what instances exist on a given volume or for a given filter, and so forth. Note that filter-user communication is different from the administration APIs that are provided which allow enumeration of filters/instances, unloading/loading filters and so forth, as the filter-user communication APIs are for use by filters to do their own private communication.
- the new filter model provides a way to write reliable, efficient, file system filters allowing dynamic load/unload, dynamic attachment/detachment to volumes, flexible ordering, and access to a rich set of APIs that filters most commonly need.
- the following provides specific details for one example implementation that is based on the Windows® NT/2000/XP operating system.
- file system filter drivers comprise NT kernel-mode drivers, and as such are required to export a function called DriverEntry( ), which is the first function invoked when the driver is loaded.
- DriverEntry( ) the first function invoked when the driver is loaded.
- filters call a function to register named FltRegisterFilter( ) in their DriverEntry( ).
- FltRegisterFilter( ) takes as a parameter an FLT_REGISTRATION structure, which contains (among other things) instance setup and teardown callbacks, a list of context callback function pointers, and a list of callback pointers for file system operations. Note that in many scenarios in which a filter wishes to hook only a relatively few number of operations, and is only interested in setting contexts for few, if any, objects, this list may be very short.
- a flags field in which a filter sets one or more filter attribute flags from which an altitude may be derived.
- a flag may be set by a filter that modifies data, such as for an encryption or compression filter to notify the system that it modifies data on the way to and from the base file system.
- any filter that splits a user's data into multiple streams also should set this flag.
- Filters can also set a flag to indicate that the filter examines data, e.g., a virus filter that that needs to see plaintext, uncompressed data would set this flag.
- Flags are also available for filters that modify standard information (such as timestamps and dates), for filters that examine standard information, (e.g., to perform different operations on a file based on its date), for filters that redirect a create to a file/stream of a different name (e.g., a symbolic link/SIS type filter), and for filters that rely on file names, (such as a virus filter that scans .EXE and .DOC files).
- standard information such as timestamps and dates
- filters that examine standard information e.g., to perform different operations on a file based on its date
- filters that redirect a create to a file/stream of a different name e.g., a symbolic link/SIS type filter
- filters that rely on file names such as a virus filter that scans .EXE and .DOC files).
- these flags may be used to help the system attach filters to a volume in the correct order.
- an antivirus filter should not be allowed to attach between an encryption filter and the base file system, since the antivirus filter needs to see the data as is, prior to encryption.
- the model does not allow a filter having a flag that indicates that the filter examines data flag set to attach above a filter with a flag set that indicates that the filter modifies data.
- certain combinations of these flags may be used to prevent a filter from attaching, e.g., if two filters set flags indicating that each filter both examines and modifies data, there is no order in which both filters can be safely attached to the same volume.
- callback data is a unit of I/O representation, somewhat analogous to an IRP, for the purpose of representing the necessary information that describes the operation to the filter driver.
- the callback data contains normalized parameters, specialized to the file system filter's uses, and exists for Fast I/O, IRP and FsFilter calls.
- the changeable parameter section can be modified (that is, dirtied) by the driver, and the parameter section is honored by filter manager from filter to filter via the completion node stack popping operation, described above.
- callback data structure typedef struct _FLT_CALLBACK_DATA ⁇ ... * FLT_CALLBACK_DATA_FLAGS Flags; // // Thread that initiated this operation. // PETHREAD Thread; PFLT_IO_PARAMETER_BLOCK Iopb; IO_STATUS_BLOCK IoStatus; ... * * // other data: reparse data buffer, queue links, // context area for filters ... * ⁇ FLT_CALLBACK_DATA, * PFLT_CALLBACK_DATA;
- I/O parameter block typedef struct _FLT_IO_PARAMETER_BLOCK ⁇ ........ « UCHAR MajorFunction; UCHAR MinorFunction; ................. PFILE_OBJECT TargetFileObject; PFLT_INSTANCE TargetInstance; // // Normalized parameters for the operation // FLT_PARAMETERS Parameters; ⁇ FLT_IO_PARAMETER_BLOCK, *PFLT_IO_PARAMETER_BLOCK;
- pre-operation callbacks may return one of the following statuses (and others) for FLT_PREOP_CALLBACK_STATUS: FLT_PREOP_SUCCESS_WITH_CALLBACK - the operation succeeded, and the filter wants to have its post-operation callback called FLT_PREOP_SUCCESS_NO_CALLBACK - the operation succeeded, but the filter does not want to have its post-operation callback called FLT_PREOP_PENDING - the filter driver will complete the operation (by calling FltCompletePendedPreOperation ( )) sometime in the future FLT_PREOP_COMPLETE - the filter has completed the operation. An operation can be failed by setting an error status and return this callback status.
- FLT_PREOP_SYNCHRONIZE the filter wants the completion processing performed in the same thread context that the pre-operation callback was performed in; the thread originating this I/O will not be returned to until this I/O is completed.
- FLT_PREOP_DISALLOW_FASTIO the filter wants to disallow the given FastIo operation; This indicates the fast I/O path is disallowed, but the I/O manager will use the regular IRP path to complete the I/O.
- the flags may include: FLTFL_POST_OPERATION_DRAINING - If set, the given instance is being detached and this post-operation routine is being called for cleanup processing.
- a filter will receive a completion callback per pre-operation callback. For instance, if memory is allocated in the pre callback, a filter can be assured it will be given a chance to free it in the completion callback, and that the completion callback won't be called more than once to provoke the filter to free the memory more than once.
- the operations for which pre- and post-callbacks may be provided include the existing IRP_MJ_codes from IRP_MJ_CREATE to IRP_MJ_PNP, IRP_MJ codes created to represent fast I/O operations for which there is no IRP equivalent, and IRP_MJ codes created to represent FS filter operations. If future operating system versions add new IRP_MJ_ codes, existing filters will be unaffected, and will not receive any callbacks for IRP_MJ_ routines that did not exist when the filter was compiled. If a filter registers with an IRP_MJ_ code that the operating system does not recognize, FltRegisterFilter( )will return a special success status, and only call the callbacks for functions that exist in that version. If a filter does not want to continue to run if one or more callbacks will not be provided, the filter can call FltUnregisterFilter( ).
- IRP_MJ_READ and IRP_MJ_WRITE will be invoked for IRP-based I/O and for fast I/O.
- the pre-callout for IRP_MJ_CREATE will not be passed contexts for the file or stream, as it is not yet determined at pre-create time what file or stream (if any) is going to be created.
- the post-callout for IRP_MJ_CLOSE will not be passed any contexts, as the system-internal structures with which they are associated are freed before the post-close routine is called.
- the pre-callbacks for IRP_MJ_CLEANUP and IRP_MJ_CLOSE must succeed and return FLT_PREOP_SUCCESS_WITH_CALLBACK or FLT_PREOP_SUCCESS_NO_CALLBACK.
- the post-operation callbacks have the potential to be called at DPC level, and therefore they should not wait for resources or mutexes, nor should they call any function that would wait. Note that routines such as FltSetFileContext( ) acquire resources and thus may not be called from post-operation callbacks.
- post callbacks return either FLT_POSTOP_STATUS_SUCCESS or FLT_POSTOP_MORE_PROCESSING_REQUIRED.
- Post-callbacks can be failed by setting an error code in the IoStatus, and in general the rule is that it is the filter's responsibility to undo what ever has occurred.
- filter instances may be dynamically detached, whereby such a filter instance will no longer be called for any operations on that volume.
- Unloading a filter essentially means that its code is no longer in memory. This will most often be done at system shutdown time and when a new version of a filter is being installed without shutting the system down.
- a filter instance can be detached even when there is outstanding I/O. In that case, the filter's completion routine or routines will be called for any outstanding I/O operations with the flag FLTFL_POST_OPERATION_DRAINING set. The fiter will not receive completion callbacks when those I/O operations actually complete.
- the system will call routines to free the filter's context, for outstanding contexts for files, streams, and stream file objects associated with that instance.
- a managed filter driver architecture that handles much of the I/O handling requirements, thereby facilitating simpler and more reliable filter drivers.
- the drivers may selectively register for only the I/O in which they are interested, improving efficiency. Dynamic load and unload, attach and detach are achieved. Other benefits include context management, including on file systems with multi-stream capabilities. The method and system thus provide significant advantages and benefits needed in contemporary computing.
Abstract
Description
- The invention relates generally to computer systems, and more particularly to file systems and file systems filters.
- With contemporary operating systems, such as Microsoft Corporation's Windows® XP operating system with an underlying file system such as the Windows® NTFS (Windows® NT File System), FAT, CDFS, SMB redirector filesystem, or WebDav file systems, one or more file system filter drivers may be inserted between the I/O manager that receives user I/O requests and the file system driver. In general, filter drivers (‘filters’) are kernel-mode drivers that enhance the underlying file system by performing various file-related computing tasks that users desire, including tasks such as passing file system I/O (requests and data) through anti-virus software, file system quota providers, file replicators and encryption/compression products. For example, antivirus products provide a filter that watches I/O to and from certain file types (.exe, .doc, and the like) looking for virus signatures, while file replication products perform file system-level mirroring. Other types of file system filter drivers are directed to system restoration (which backs up system files when changes are about to be made so that the user can return to the original state), disk quota enforcement, backup of open files, undeletion of deleted files, encryption of files, and so forth. Thus, by installing file system filter drivers, computer users can select the file system features they want and need, in a manner that enables upgrades, replacement, insertion, removal of the components without necessitating the changing the actual operating system or file system driver code.
- The existing file system filter model in contemporary Windows®-based operating systems (e.g., Windows® NT, Windows® 2000, Windows® XP, Windows® .NET Server 2003) leverages the inherent I/O model, which is a packet-based approach. To this end, file system filters load as regular drivers in a stack and attach to the underlying file system's volume device objects. User I/O requests are converted by an I/O manager into I/O Request Packets (IRPs), which are sent to the driver stack and processed by the top driver, which may complete it, pass it down in a call to another driver towards the file system, which calls the next lower driver, and so on. In general, each driver does whatever processing it is coded to perform on the IRP, and then explicitly passes down the IRP to the next lower driver (or file system if none are lower), or completes (or fails) the IRP and sends it back up the stack to the next higher driver (or the I/O manager if none are higher).
- Although this existing filter driver model provides a number of benefits including being highly flexible, there are also a number of inherent problems with it. For one, writing a file system filter is a non-trivial task, primarily as a result of the underlying complexity of a file system. Filters are highly complex pieces of software that are traditionally hard to debug and maintain. Much of the complexity arises from the filters' handling of the packets, e.g., the need to understand and manipulate IRPs. As a result, reliability suffers, and at least one study has shown that filters have been responsible for a significant percentage of system crashes.
- Another problem is efficiency, as file system filters traditionally receive and process every operation that normally goes to a file system, even those in which they have no interest in. For example, an antivirus product can slow down a system as much as sixty percent, but not every I/O request received by an antivirus filter is one that the filter will do anything with, namely inspect any corresponding data for viruses. Redundancy is also a problem that leads to inefficiency and computing cost, as many filters do the same things in different ways, leading to unnecessary code.
- Interoperability between drivers is also a significant problem, as, for example, one driver may modify I/O in a way that the other driver does not anticipate and cannot properly deal with. Note that interoperability problems are one of the biggest drawbacks of the existing model, in part because filters have only a very coarse-grained control over attachment ordering to a file system.
- Other problems include overflowing stack space, because when two or more filters are installed, stack overflows are common due to recursive reentrant I/O issued by filters. Deadlocks are also common in the existing model, again primarily due to re-entrant I/O. Other problems include the inability to dynamically load and unload filters in the stack, that is, without a system reboot.
- In sum, the existing filter driver model has a number of significant drawbacks. What is needed is an improved model and architecture for file system filters to handle file system I/O requests and associated data.
- Briefly, the present invention provides a model/architecture in which filter drivers are managed by a filter manager to receive callbacks for I/O requests in which the filter drivers have registered an interest. The model eliminates traditional, complex I/O passing by providing a managed callback model, in which IRPs, fast I/O paths, Fs Filter callbacks and so forth are translated by a filter manager into callbacks that provide callback data in an explicit, well-defined format into the filters. The filters manipulate the callback data as desired, and return a status in response to the callback, as described below. As one result, filters no longer have to deal with IRPs.
- In general, a filter manager translates the I/O, whether an IRP, fast I/O, FS Filter callback or the like, into a uniform structure known as ‘callback data’. To this end, the filter manager may be placed into the legacy filter driver stack as if it is a legacy filter driver, so that it can receive and process IRPs. The filter manager then walks through a list of appropriately registered filter drivers to invoke a registered dispatch for the I/O.
- Filter drivers comprise may objects (or similar such components) that when instantiated register with a registration mechanism in the filter manager. The filter drivers only register for file system requests in which they may be interested in processing, by notifying the filter manager of the types of I/O requests in which it is interested (e.g., create, read, write, close and so forth). As a result, the model is more efficient than a stacked filter model, because filter drivers do not see I/O requests that they are not interested in, and thus have not registered for.
- In one implementation, filter drivers separately attach to volumes as filter driver instances, on a per-volume basis, and a filter driver may attach multiple instances to the same volume. Each filter driver instance is associated with an ‘altitude’ which indicates where in the callback order that driver is located. The altitude may be pre-defined, or derived from flags provide by the driver that indicate the type of processing the driver will perform on the callback data.
- To efficiently track which filter drivers have registered for which types of callbacks and thereby efficiently callback the appropriate drivers in the proper order, the filter manager maintains per-volume, ordered lists, each list indexed by a type of operation for which filters have registered interest in receiving pre-callbacks and/or post-callbacks. The filter manager uses this list to callback the filters in the appropriate order, and each filter returns a status. Assuming success, following the last pre-callback, the filter manager reconverts the callback data to an IRP and sends the IRP to the file system.
- Post-callback essentially works in the opposite order, although a filter can indicate that it wants to be skipped over during the post-callbacks. I/O completion is handled by the filter manager in a manner that guarantees that the parameters seen by a filter instance in its pre-callback are the same in its post-callback. To this end, the filter manager maintains a completion node stack which it accesses to return the correct parameters in each post callback.
- The filter manager also provides a rich API set that provides functions which filters commonly need. For example, certain filters need to perform I/O of their own, and various functions are provided that facilitate such operations. Various functions also provide efficient context support with instances, volumes, files, stream handles, or streams keeping track of the context data for each filter in association with the appropriate object. The present invention provides notification support via a set of callbacks that setup notification for an entity, and simplifies the association of a per-filter context with that entity. Contexts may be set and/or reset any time. Still other functions enable communication between kernel mode filter drivers and user mode counterpart services and programs, while other functions provide naming support as described in U.S. patent application Ser. No. 10/187119, filed on Aug. 28, 2002.
- Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which:
-
FIG. 1 is a block diagram generally representing a computer system into which the present invention may be incorporated; -
FIG. 2 is a block diagram generally representing an architecture including components for managing the I/O to filters in accordance with an aspect of the present invention; -
FIG. 3 is a block diagram generally representing instances of managed filters in accordance with an aspect of the present invention; -
FIG. 4 is a block diagram generally representing data structures used by a filter manager to selectively pass I/O to appropriately registered filters in accordance with an aspect of the present invention; -
FIG. 5 is a representation of a stack of completion nodes for returning callback data to registered filter drivers in a post-callback operation in accordance with an aspect of the present invention; -
FIG. 6 is a block diagram representing a tree for efficient determination of which instances have context data in accordance with an aspect of the present invention; and -
FIG. 7 is a block diagram representing the returning context data to a filter driver in accordance with an aspect of the present invention. - Exemplary Operating Environment
-
FIG. 1 illustrates an example of a suitablecomputing system environment 100 on which the invention may be implemented. Thecomputing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in theexemplary operating environment 100. - The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
- The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
- With reference to
FIG. 1 , an exemplary system for implementing the invention includes a general purpose computing device in the form of acomputer 110. Components of thecomputer 110 may include, but are not limited to, aprocessing unit 120, asystem memory 130, and asystem bus 121 that couples various system components including the system memory to theprocessing unit 120. Thesystem bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus. - The
computer 110 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by thecomputer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by thecomputer 110. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media. - The
system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements withincomputer 110, such as during start-up, is typically stored inROM 131.RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processingunit 120. By way of example, and not limitation,FIG. 1 illustratesoperating system 134,file system 135,application programs 136,other program modules 137 andprogram data 138. - The
computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates ahard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, amagnetic disk drive 151 that reads from or writes to a removable, nonvolatilemagnetic disk 152, and anoptical disk drive 155 that reads from or writes to a removable, nonvolatileoptical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. Thehard disk drive 141 is typically connected to thesystem bus 121 through a non-removable memory interface such asinterface 140, andmagnetic disk drive 151 andoptical disk drive 155 are typically connected to thesystem bus 121 by a removable memory interface, such asinterface 150. - The drives and their associated computer storage media, discussed above and illustrated in
FIG. 1 , provide storage of computer-readable instructions, data structures, program modules and other data for thecomputer 110. InFIG. 1 , for example,hard disk drive 141 is illustrated as storingoperating system 144,application programs 145,other program modules 146 andprogram data 147. Note that these components can either be the same as or different fromoperating system 134,application programs 136,other program modules 137, andprogram data 138.Operating system 144,application programs 145,other program modules 146, andprogram data 147 are given different numbers herein to illustrate that, at a minimum, they are different copies. A user may enter commands and information into thecomputer 110 through input devices such as a tablet (electronic digitizer) 164, a microphone 163, akeyboard 162 andpointing device 161, commonly referred to as mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to theprocessing unit 120 through auser input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). Amonitor 191 or other type of display device is also connected to thesystem bus 121 via an interface, such as avideo interface 190. Themonitor 191 may also be integrated with a touch-screen panel or the like. Note that the monitor and/or touch screen panel can be physically coupled to a housing in which thecomputing device 110 is incorporated, such as in a tablet-type personal computer. In addition, computers such as thecomputing device 110 may also include other peripheral output devices such asspeakers 195 andprinter 196, which may be connected through an outputperipheral interface 194 or the like. - The
computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as aremote computer 180. Theremote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to thecomputer 110, although only amemory storage device 181 has been illustrated inFIG. 1 . The logical connections depicted inFIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. For example, in the present invention, thecomputer system 110 may comprise source machine from which data is being migrated, and theremote computer 180 may comprise the destination machine. Note however that source and destination machines need not be connected by a network or any other means, but instead, data may be migrated via any media capable of being written by the source platform and read by the destination platform or platforms. - When used in a LAN networking environment, the
computer 110 is connected to theLAN 171 through a network interface oradapter 170. When used in a WAN networking environment, thecomputer 110 typically includes amodem 172 or other means for establishing communications over theWAN 173, such as the Internet. Themodem 172, which may be internal or external, may be connected to thesystem bus 121 via theuser input interface 160 or other appropriate mechanism. In a networked environment, program modules depicted relative to thecomputer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,FIG. 1 illustratesremote application programs 185 as residing onmemory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. - Managed File System Filter Model and Architecture
- The present invention is generally directed towards a file system filter model and architecture that is intended to improve file system I/O handling by filters, including by facilitating the interoperability among various file system-related products. Note that the model is generally described herein with reference to filter drivers that operate between the I/O manager and a base file system, which can be a local or remote file system, and not described with reference to other drivers, including filter drivers that operate between the file system and the storage driver or drivers (such as FtDisk or DMIO).
- As used herein, “legacy” filter drivers are those that handle I/O request packets (IRPs) in the traditional manner, rather than by the new model, which uses callbacks to registered filter drivers as described below. As it is expected that legacy filter drivers will be phased out over time, filter drivers that comply with the new registration and callback model will be referred to herein simply as “filter drivers.”
- One of the primary aspects of the new filter model is directed to eliminating traditional, complex I/O passing from legacy filter to legacy filter through a stack model, and replace that model with a managed callback model, in which IRPs, fast I/O paths, memory manager callbacks and so forth are translated by a filter manager into callbacks that provide callback data in a defined format into the filters. The filters do not call other filters, or directly pass control to other filters, but rather manipulate the callback data as desired, and return a status in response to the callback, as described below. Since filters no longer have to deal with IRPs and the like, much of the I/O handling complexity is removed from the filters and built into a single filter manager, eliminating many of the problems caused by various filters. For example, IRPs often contain implicit, complex information that legacy filter drivers have traditionally had difficulty in dealing with; the present invention eliminates this problem by having the filter manager deal with the implicit information, and pass only explicit context to the filters. The callback model further has the benefit of solving stack overflow and locking issues that arise due to chained IRP dispatches.
-
FIG. 2 represents anexample implementation 200 of the new model. One advantage of the implementation represented inFIG. 2 is that existing applications, operating system components and file systems need not be modified in any way to implement the new model. For example, in a Windows®-based operating system, anapplication 202 will still continue to make file system requests (e.g., via function/method calls) through anAPI layer 204 to an I/O manager 206. As is known, the I/O manager 206 generates an IRP or other type of I/O, and sends the I/O to the top of the (legacy)filter driver stack 208. As described below, one of the components in thestack 208 is afilter manager 212. - In general, the
filter manager 212 translates the I/O, whether an IRP, fast I/O, FS Filter callback or the like into a uniform structure known as callback data. A suitable callback data structure is described below. Thefilter manager 212 then walks through a list of registered filter drivers (e.g., five such filter drivers 282 A-282 E are shown inFIG. 2 , although there may be any practical number of such drivers), and for each filter driver, may invoke a registered dispatch for the I/O. Significantly, in the model of the present invention, filters do not receive and/or handle IRPs, but instead essentially instruct thefilter manager 212 on what to do with the I/O request. - As also represented in
FIG. 2 ,legacy filter drivers 210 may still be supported in this implementation, such as by placing them at the top of thestack 210. Note however that it is feasible to arrange them in some other order relative to other stack components. For example, since legacy filter drivers are arranged to handle IRPs, not callbacks, special management code may surround such a legacy filter to generate an IRP from callback data to pass to it and receive the (possibly modified) IRP from it and convert it back to a status response. In this manner, a legacy filter can be inserted and isolated within the callback model. In any event, legacy filters may still be used in the new model. - To summarize the implementation shown in
FIG. 2 , the filesystem filter manager 212 is employed in the new model, and placed into thefilter driver stack 208 as if it is a legacy filter driver, so that it can receive and process IRPs. Note that this allows the filter manager to simply work in an existing I/O system, however it can be appreciated that an equivalent model (e.g., without higher legacy filters) can be provided in which an updated I/O manager passes I/O data to a filter manager in something other than an IRP data structure. For example, when the I/O manager generates an IRP, the filter driver generates a callback data structure from the IRP, and thus it may be more efficient to have the I/O manager directly generate the callback data structure. Note that something other than an IRP is already provided in existing systems for fast I/O, memory manager callbacks and so forth, which for faster performance are callback-based rather than packet-based, for some common I/O tasks such as read/write/device I/O controls. Further, note that in existing systems, fast I/O is still passed through the stack (that is, chained), and is thus not like the callback-based model of the present invention. For purposes of simplicity, the present description will primarily use the example of an IRP, except where otherwise noted. - In one implementation, filter drivers comprise objects or the like that when instantiated, typically during their driver initialization procedure, register with a registration mechanism in the
filter manager 212. For efficiency, the filter drivers typically will only register for file system requests in which they may be interested in processing. To this end, as part of the registration, each filter driver notifies the filter manager for the types of I/O requests in which it is interested (e.g., create, read, write, close and so forth). For example, an encryption filter driver may register for read and write IRPs, but not for others wherein data does not have to be encrypted or decrypted. Similarly, a quota filter may be interested only in file creates and file writes. As a result, the model is more efficient than a stacked filter model, because filter drivers only see the I/O for which they have registered. - To enable attachment to volumes, the model of the present invention defines the concept of an “instance” of a filter driver (and also a volume context as described below). More particularly, filter drivers that wish to attach to a volume are notified via an instance setup notification when a new volume is mounted. A similar notification is provided for volumes that have already mounted before a filter driver is loaded. Filter drivers can then choose to attach to the volume via registration, described below, and if so, an instance object is used to represent the instance of the attachment. Filter drivers are similarly notified when a volume dismounts, namely through an instance detach notification. The present model also allows for filter drivers to dynamically detach from a mounted volume.
- A filter driver may be associated with an altitude which indicates where in the callback order that driver is located, such as generally described in U.S. patent application Ser. No. 09/768,098 entitled “Method and System for Deterministic Ordering of Software Modules.” Moreover, as represented in
FIG. 3 , filter drivers can attach multiple times to the same volume, creating an instance for each attachment, (although to do so, each instance for the same volume is necessarily at a different altitude, whether by an order number or by some override mechanism). -
FIG. 3 shows an example filter that has multiple instances. InFIG. 3 , filter A, e.g., a “filesystem activity monitoring” filter, monitors file I/O, and has two instances, filter A and filter A′. In this manner, a file activity monitoring product is able to observe (via filter A) I/O going in to an intermediate (e.g., anti-virus) filter B, as well as observe (via filter A′) the I/O that eventually passes through that intermediate filter on its way towards the file system. For example, the file activity monitoring product may include a user mode program (not separately shown) which both filter A and filter A′ report to, via messages as described below. - Thus, per-volume filter driver instances may be associated with an altitude that determines where each instance is located for that volume. Altitudes may be pre-assigned to a given filter instance, such as in U.S. patent application Ser. No. 09/768,098, and/or a flag mechanism or the like (described below) may be used to derive an appropriate altitude for a filter. For example, an antivirus filter should not be allowed to attach between an encryption filter and the base file system, since it needs to see the data as is, prior to encryption. Flags can indicate whether a filter inspects data (e.g., an antivirus filter), modifies data, (e.g., an encryption filter), and so forth, from which an altitude may be derived. In this manner, the callback order is not based on the order in which drivers are loaded, but rather on some predetermined, logical basis.
- In accordance with one aspect of the present invention, filter drivers register two kinds of callbacks, namely pre-callbacks and post callbacks. The pre-callback is called on the I/O's way down, that is, towards the file system, while the post-callback is called during the completion of the I/O, on the way back up from the file system towards the I/O manager.
- For efficiency, to track which filter drivers have registered for which types of callbacks and thereby efficiently determine which filter drivers to call when I/O (e.g., an IRP) is received, the
filter manager 212 maintains one or more per-volume data structures. For example, as represented inFIG. 4 , when a filter instance registers at a registration mechanism 402 (e.g., by calling a function) in thefilter manager 212, the registration mechanism determines, via anordering mechanism 404 where in the pre-callback order the filter instance belongs. Theordering mechanism 404 may be based on a simple comparison of altitudes, or may include logic that evaluates flags to determine where the filter instance fits in. In any event, per-volume callback nodes are maintained, with the registration information therein. - As described below, part of the information sent to the filter manager in registration comprises (e.g., in an array) a list of the file system requests for which a filter instance wants a pre-callback. This information is used to construct a per-volume ordered list 408 (e.g., volume c:) or 410 (e.g., volume d:) or the like by which a
callback mechanism 412 in thefilter manager 212 can efficiently determine the order for calling each instance. For example, as represented inFIG. 4 , if a read request for a file on the c: volume is received, the filter instances interested in read (as indexed by IRP major code of the IRP) may be quickly obtained, e.g., filter instance A, filter instance B and filter instance A′ will be the pre-callback order, as represented in the example inFIG. 4 . Note that this is highly efficient, and also facilitates dynamic registration; at any time a new filter instance registers, the registration mechanism can rebuild the lists as appropriate. - In this manner, the pre-callback order is determined per type of file I/O request, although as described below, the status returned by each filter instance may impact the actual filter instances that receive callbacks, e.g., a filter can fail a callback. Post-callback works essentially in the opposite order, however as described below, one of the status values that a called instance can return in a pre-callback is success without a post callback, in which case the
filter manager 212 will skip the post callback for that instance. - The status values that a filter instance may return in response to a callback generally include success without callback, success with callback, pending, synchronize, complete, and disallow fast I/O. In one particular implementation “FLT_PREOP_SUCCESS_NO_CALLBACK” continues processing the I/O pass through, as does the status “FLT_PREOP_SUCCESS_WITH_CALLBACK,” which further requests a completion callback when this I/O completes. A filter can also specify FLT_PREOP_PENDING, which holds the I/O until the filter later calls FltCompletePendedPreOperation( ). FLT_PREOP_SYNCHRONIZE waits for the I/O to complete, and calls post-callback in the original thread context. The I/O synchronization is handled by the Filter Manager. Note that “pending” and “synchronize” cannot be returned with fast I/O. FLT_PREOP_COMPLETE completes the I/O with either a success or failure status code (which is generally analogous to an IoCompleteRequest in a legacy dispatch). FLT_PREOP_DISALLOW_FAST_IO is valid only for Fast I/O, and is generally equivalent to returning FALSE in a legacy dispatch.
- In this manner, the managed filter driver model allows filter drivers to control the execution path of the I/O via the return status from their pre-callback routine. This allows filter drivers to request different ways for the I/O to be handled, including pended, completed, passed on to lower filters, request a post-callback, request a ‘synchronized’ post-callback and so forth.
- As described herein, filter instances register for post-callbacks. In response to a post callback, a filter instance (e.g., that previously returned a status of FLT_PREOP_SUCCESS_WITH_CALLBACK) can return a status of FLT_POSTOP_FINISHED_PROCESSING to continue I/O completion, or FLT_POSTOP_MORE_PROCESSING_REQUIRED to abandon completion and complete I/O later by calling a FltCompletePendedPostOperation( ) function. A filter can reissue an I/O during its post-operation processing via the FltReissueSynchronousIo( ) function call for reparse handlers. A FLT_POSTOP_UNDO_CREATE status is provided for filters that want to block file opens by failing the create request.
- I/O completion is handled by the
filter manager 212 in a manner that guarantees that the parameters seen by a filter instance in its pre-callback are the same in its post-callback. Note that this is an improvement over the legacy stacked model in which filters often changed parameters, buffer pointers and so on, leading to numerous problems. In general, this is performed as represented inFIG. 5 , wherein the filter manager maintains a completion node for each instance, (that is, at least for those instances receiving callbacks). - In essence, for each instance called in a pre-callback that has (via its status) requested a callback, the filter manager takes a snapshot of the parameters before each pre-callback, stores the snapshot in the completion node, and pushes the completion node onto a
stack 502. To manage the post-callback data, for each IRP, the filter manager maintains anIRPCTRL header 504, not seen by the filter driver, that tracks information including the device object, an IRP pointer, node information including the size of the completion nodes and its corresponding instance, and so forth. Then, during post-callback, the filter manager essentially walks backwards, popping each completion node off of thestack 504 and putting the completion node data into thecallback data 506 for that instance, thereby restoring its parameters. Note that the stack can be copied to another stack with an added completion node if a filter instance registers dynamically before it is pre-called in the order; if registered after the pre-calling has already passed it in the pre-calling order for a given IRP, that instance would not be called back. - For efficiency, the stack only needs to have a completion node pushed onto the stack when a filter instance is to receive a callback, and when a filter instance makes a change to the callback data, since otherwise the same completion node can be reused. A filter instance is responsible for setting a “dirtied” parameters flag when it modifies the data. Note that if it does not do so, its changes will be discarded and it will not have its changed data snapshotted, whereby any changes would not be seen by another driver.
- Returning to
FIG. 2 , after the last post-callback is made, thefilter manager 212 reconverts (marshals) the callback data into an IRP and returns the IRP up the stack towards the I/O manager 206, through any higher legacy filters 210. As can be appreciated, with this managed filter model many of the drawbacks of the legacy model are eliminated or significantly reduced. - In addition to the above functions, the filter manager also provides a rich API set that provides functions which filters commonly need. For example, certain filters need to perform I/O of their own, e.g., an anti-virus filter may wish to read a file before it is opened. When a filter driver wishes to initiate its own I/O operation, it first calls FltAllocateCallbackData( ). This function allocates and returns an FLT_CALLBACK_DATA structure, which the filter then populates with any relevant fields. Note that FltAllocateCallbackData is essentially the replacement for calling IoAllocateIrp( ) in the legacy system. When the filter is ready to send the I/O request on to any remaining filters, legacy filters, and the base file system, it calls FltPerformSynchronousIo( ) or FltPerformAsynchronousIo( ) (analogous to IoCallDriver( )). By default, filter-initiated I/O is sent to the next attached filter for the given volume, bypassing any filters attached above the filter initiating the I/O. It is possible, however, to send I/O to any device in the system, as a hierarchical storage management (HSM) filter might need to do.
- As another example, filters sometimes need to create a file, and the FltCreateFile( ) function is provided as a starting point for initiating I/O. This function returns a handle that can be used with existing operating system APIs that take file handles, and allows file create on other instances. The function supports share-access override. Further, the filter manager ensures that any callbacks are only seen by filters below the requesting filter, including those dynamically inserted, which, as can be appreciated, avoids recursive callbacks. To this end, the filter manager creates a file with an instance hint, and uses this hint to identify the requesting filter. Note that mount point opens are an exception, as they need to go to top of the callback stack.
- FltReadFile( ) allows synchronous and asynchronous I/O, with filter-supplied callback that will be issued on I/O completion. FltWriteFile( ), FltSetInformationFile( ) and so forth have similar semantics. FltAllocateCallbackData( ) allows I/O to be customized, including FltPerformSynchronousIo( ), or FltPerformAsynchronousIo( ) which accepts an I/O completion callback.
- Context management is another example where filter manager-provided APIs are highly beneficial, as filters often need to associate a context structure with each stream handle, stream, instance and volume. For example, filters use the contexts to store per handle/per stream/per file/per volume/per instance information that is looked up when a filter intercepts I/O. Any context or contexts that a filter has set on an entity will be passed to the filter when that filter requests it, e.g., via an API. The context lifetime is managed by the
filter manager 212, and filters will be called back when the context is deleted due to the appropriate object (such as stream/file/instance/volume) being deleted. - In accordance with another aspect of the present invention, the
filter manager 212 provides efficient context support to store context data (e.g., pointers or the like) for each filter in the appropriate object, that is, for a stream handle, stream, file, instance or volume. To this end, the present invention provides context support, via a set of APIs that return context to an entity, and thus simplifies the association of a per-filter context with that entity. Contexts may be set and/or reset any time. The present invention also provides notification support for instances, via a set of callbacks that setup notification for an instance. - The types of entities include instances, volumes (a local disk volume, or a remote network share), streams (for file systems that support multiple streams per file), stream handles (per-file objects), and files (e.g., all streams of a file). With respect to instances, as described above, when a filter attaches to a volume, an instance is created, and, as also described above, there may be more than one instance of a given filter for a given volume, e.g., attached both above and below another filter on the same volume. Each instance can have a context associated, for example to point to a private log for that instance. A volume context can be shared among filter instances.
- To associate a context with an object, the filter calls FltAllocateContext( ) specifying the type of context (stream handle, stream, file, instance or volume), the size of context and whether the context should be allocated from paged or non-paged pool memory. Once the context is allocated and initialized, the filter associates the context with the object by calling the appropriate routine: FltSetStreamHandleContext( ), FltSetStreamContext( ), FltSetFileContext( ), FltSetInstanceContext( ) or FltSetVolumeContext( ).
- As represented in
FIG. 6 , to efficiently look up the filter instances associated with files, streams and stream handles, thefilter manager 212 adds a tree (e.g. a splay tree) to the data structures associated with the file object. More particularly, the operating system facilitates the adding of arbitrary context to a stream, and thefilter manager 212 uses this mechanism to add astream control list 608 and atree 610 to theFSRTL_ADVANCED_FCB_HEADER 612, which essentially is pointed to by thefile object 614 via itscontext 616. Each node in thetree 610 represents a filter instance that has an associated context for this stream. Although not separately shown, there may be parallel trees, one for paged-pool memory and one for non-paged pool memory, as specified by the filter instance for different types of access that may be needed. - For a given stream handle, each node in the tree is accessed by keys, including the file object as one key and the instance as another. Note that for streams, the file object key is NULL. As represented in
FIG. 7 , when provided with these keys, such as via data in a function call to acontext mechanism 412 within (or associated with) thefilter manager 212, the appropriate node in thetree 610 can be quickly located for thefilter driver instance 702, and the appropriate context 704 (e.g., in the form of a context pointer) returned to the requestingfilter driver instance 702. In part the traversal is fast because there are not generally that many filter instances in a given configuration. - In one implementation, a filter may receive a notification for an instance:
typedef PVOID PFLT_CONTEXT; NTSTATUS (*PFLT_INSTANCE_SETUP_CALLBACK) ( IN CONST PFLT_RELATED_OBJECTS FltObjects, IN FLT_INSTANCE_SETUP_FLAGS Flags, IN DEVICE_TYPE VolumeDeviceType );
If context is needed for a particular instance, it can set it in this callback. The context is a PVOID, and the system will treat it as completely opaque, so a filter can use it to store a flags field, a counter, a pointer, or anything else it needs. If the filter was able to successfully initialize its instance callback and would like to monitor activity on this volume, it should return STATUS_SUCCESS. If the filter does not want this instance to be created on this volume, STATUS_FLT_DO_NOT_ATTACH should be returned. Notification cleanup callbacks for instances are provided to properly synchronize instance teardown as new operations may be coming to the volume, and include InstanceQueryTeardown, InstanceTeardownStart and InstanceTeardownComplete. - A filter that provides a context structure for some entity will have its corresponding ContextCleanupCallback called. In other words, to avoid leaking memory pool, a filter does not need to keep track of which contexts it has allocated, as the system will take care of when cleanup should occur. When a context should be freed, the system calls the filter's ContextCleanupCallback. During this callback, the filter is responsible to uninitialize the contents of the context and upon return the system will free the memory allocated by the filter's earlier FltAllocateContext( ) call. Cleanups are assumed to succeed; therefore there need not be a return value. The system also guarantees that the context cleanups routines will be called at an IRQL low enough that pool frees can be done safely.
- An instance context gets cleaned up when the filter is detached from the volume. A volume context gets cleaned up after the volume is dismounted, and after all files, streams, and stream handles for the volume are cleaned up. Due to memory manager, cache manager, and file system implementation details, the volume context may not be cleaned up for a relatively long time after the volume is dismounted.
- A file context gets cleaned up when the file system frees the memory associated with the file, which in a multiple-stream file system, will be after the last stream handle for the last stream for that file is freed. Note that because the operating system's memory manager and cache manager may still have references to one or more streams in the file, the file context may not be cleaned up for a relatively long time after the last user handle to the stream is closed. Similarly, a stream context gets cleaned up when the file system frees the memory associated with the stream, which will be after the last stream handle for that stream is freed. Again, because the operating system's memory manager and cache manager may still have references to one or more streams in the file, the stream context may not be cleaned up for a relatively long time after the last user handle to the stream is closed.
- A stream handle context gets cleaned up when the last reference to the stream handle is released. This may be as a result of the user handle being closed, or the last memory manager or cache manager reference being released.
- A context can be set for an object if the object does not currently have a context, or a context can be changed. A filter can clear a context using one of the following routines, as appropriate: FltDeleteContext( ), FltDeleteVolumeContext( ), FltDeleteInstanceContext( ), FltDeleteFileContext( ), FltDeleteStreamContext( ) and FltDeleteStreamHandleContext( ).
- Often a filter will want some basic information about an entity to decide if it is interested in it. For a volume, this might be the file system, whether the volume is local or remote, whether it is on removable media, and so on. For a file, this may include the file's name, timestamps, size, extension, and so forth. The system may expose functions (e.g., FltGetFileInformation( ), FltGetVolumeInformation( )) to conveniently retrieve this information. The filter may also wish to call FltTagFile( ) to set a reparse point on a file.
- Yet another set of APIs provide by the architecture of the present invention, are directed towards facilitating communication between filter instances and user mode code. More particularly, many filters have a user-mode service counterpart that is typically the administrative component of the product, and filters need to communicate with the service. The present architecture may provide APIs for these products to use for both user-mode initiated as well as kernel-initiated communication.
- For example, for filters that communicate with a user-mode component, a library is available for those user-mode applications. The library exposes routines, including routines to load and unload filters, attach and detach filters to volumes, open communication channels to filters from user-mode and send/receive data from the filters, and query the system for information on the current status of the system. For example, a user mode program may query for which filters are currently loaded, what instances exist on a given volume or for a given filter, and so forth. Note that that filter-user communication is different from the administration APIs that are provided which allow enumeration of filters/instances, unloading/loading filters and so forth, as the filter-user communication APIs are for use by filters to do their own private communication.
- In summary the new filter model provides a way to write reliable, efficient, file system filters allowing dynamic load/unload, dynamic attachment/detachment to volumes, flexible ordering, and access to a rich set of APIs that filters most commonly need. The following provides specific details for one example implementation that is based on the Windows® NT/2000/XP operating system.
- The following describes some of the filter-initiated operations performed via function calls, including registration with the filter manager:
- Filter declares callbacks for interesting I/O:
FLT_OPERATION_REGISTRATION Callbacks[] = { { IRP_MJ_CREATE, 0, // Flags AvCreate, // pre-callback AvCreateCompletion}, // post-callback { IRP_MJ_WRITE, 0, AvWrite, AvWriteCompletion}, ... }; - Filter declares a registration structure:
const FLT_REGISTRATION FilterRegistration = { ... * AvUnload, // Unload routine AvInstanceSetup, // Instance Setup AvInstanceQueryTeardown, AvInstanceTeardownStart, AvInstanceTeardownComplete, ...... Callbacks, // Operation callbacks }; - Filter registers with filter manager:
status = FltRegisterFilter( DriverObject, &FilterRegistration, &AvFilterHandle ); - Filter get pre-callbacks:
FLT_PRE_OPERATION_CALLBACK_STATUS AvWrite ( IN OUT PFLT_CALLBACK_DATA Data, IN CONST PFLT_RELATED_OBJECTS FltObjects, OUT PVOID *CompletionContext ); - In this example implementation, file system filter drivers comprise NT kernel-mode drivers, and as such are required to export a function called DriverEntry( ), which is the first function invoked when the driver is loaded. When loaded, filters call a function to register named FltRegisterFilter( ) in their DriverEntry( ). FltRegisterFilter( )takes as a parameter an FLT_REGISTRATION structure, which contains (among other things) instance setup and teardown callbacks, a list of context callback function pointers, and a list of callback pointers for file system operations. Note that in many scenarios in which a filter wishes to hook only a relatively few number of operations, and is only interested in setting contexts for few, if any, objects, this list may be very short.
- In one alternative implementation, there may be a flags field in which a filter sets one or more filter attribute flags from which an altitude may be derived. For example, a flag may be set by a filter that modifies data, such as for an encryption or compression filter to notify the system that it modifies data on the way to and from the base file system. In this implementation, any filter that splits a user's data into multiple streams also should set this flag. Filters can also set a flag to indicate that the filter examines data, e.g., a virus filter that that needs to see plaintext, uncompressed data would set this flag. Flags are also available for filters that modify standard information (such as timestamps and dates), for filters that examine standard information, (e.g., to perform different operations on a file based on its date), for filters that redirect a create to a file/stream of a different name (e.g., a symbolic link/SIS type filter), and for filters that rely on file names, (such as a virus filter that scans .EXE and .DOC files).
- As described above, these flags may be used to help the system attach filters to a volume in the correct order. For example, an antivirus filter should not be allowed to attach between an encryption filter and the base file system, since the antivirus filter needs to see the data as is, prior to encryption. To prevent this, the model does not allow a filter having a flag that indicates that the filter examines data flag set to attach above a filter with a flag set that indicates that the filter modifies data. Further, certain combinations of these flags may be used to prevent a filter from attaching, e.g., if two filters set flags indicating that each filter both examines and modifies data, there is no order in which both filters can be safely attached to the same volume.
- The following sets forth one logical ordering for types of file system filter drivers:
Activity Monitor (file spy etc.) Undelete Anti-virus Replication Continuous backup Content screener Quota management Cluster file system HSM (3rd party hierarchical storage management) Compression Encryption Physical Quota Management Open File backup (snapshots of open files) Security Enhancer Copy protection System Filter Infrastructure (filter manager) - As described above, callback data is a unit of I/O representation, somewhat analogous to an IRP, for the purpose of representing the necessary information that describes the operation to the filter driver. The callback data contains normalized parameters, specialized to the file system filter's uses, and exists for Fast I/O, IRP and FsFilter calls. The changeable parameter section can be modified (that is, dirtied) by the driver, and the parameter section is honored by filter manager from filter to filter via the completion node stack popping operation, described above.
- The following is an example callback data structure:
typedef struct _FLT_CALLBACK_DATA { ... * FLT_CALLBACK_DATA_FLAGS Flags; // // Thread that initiated this operation. // PETHREAD Thread; PFLT_IO_PARAMETER_BLOCK Iopb; IO_STATUS_BLOCK IoStatus; ... * * // other data: reparse data buffer, queue links, // context area for filters ... * } FLT_CALLBACK_DATA, * PFLT_CALLBACK_DATA; - The following is an example I/O parameter block:
typedef struct _FLT_IO_PARAMETER_BLOCK { .............. UCHAR MajorFunction; UCHAR MinorFunction; ................. PFILE_OBJECT TargetFileObject; PFLT_INSTANCE TargetInstance; // // Normalized parameters for the operation // FLT_PARAMETERS Parameters; } FLT_IO_PARAMETER_BLOCK, *PFLT_IO_PARAMETER_BLOCK; - Pre-operation callbacks have the same signature:
FLT_PREOP_CALLBACK_STATUS (*PFLT_PRE_OPERATION_CALLBACK) ( IN OUT PFLT_CALLBACK_DATA Data, IN CONST PFLT_RELATED_OBJECTS FltObjects, OUT PVOID *CompletionContext); - As described above, pre-operation callbacks may return one of the following statuses (and others) for FLT_PREOP_CALLBACK_STATUS:
FLT_PREOP_SUCCESS_WITH_CALLBACK - the operation succeeded, and the filter wants to have its post-operation callback called FLT_PREOP_SUCCESS_NO_CALLBACK - the operation succeeded, but the filter does not want to have its post-operation callback called FLT_PREOP_PENDING - the filter driver will complete the operation (by calling FltCompletePendedPreOperation ( )) sometime in the future FLT_PREOP_COMPLETE - the filter has completed the operation. An operation can be failed by setting an error status and return this callback status. FLT_PREOP_SYNCHRONIZE - the filter wants the completion processing performed in the same thread context that the pre-operation callback was performed in; the thread originating this I/O will not be returned to until this I/O is completed. FLT_PREOP_DISALLOW_FASTIO - the filter wants to disallow the given FastIo operation; This indicates the fast I/O path is disallowed, but the I/O manager will use the regular IRP path to complete the I/O. - Post-operation callbacks have the same signature:
FLT_POSTOP_CALLBACK_STATUS (*PFLT_POST_OPERATION_CALLBACK) ( IN OUT PFLT_CALLBACK_DATA Data, IN CONST PFLT_RELATED_OBJECTS FltObjects, IN PVOID CompletionContext, IN FLT_POST_OPERATION_FLAGS Flags); - The flags may include:
FLTFL_POST_OPERATION_DRAINING - If set, the given instance is being detached and this post-operation routine is being called for cleanup processing. - FTL_POSTOP_CALLBACK_STATUS:
FLT_POSTOP_FINISHED_PROCESSING - the filter has completed processing the operation FLT_POSTOP_MORE_PROCESSING_REQUIRED - the filter driver will complete the operation (by calling FltCompletePendedPostOperation) sometime in the future FLT_POSTOP_UNDO_CREATE - the filter wants to undo the given create operation - A filter will receive a completion callback per pre-operation callback. For instance, if memory is allocated in the pre callback, a filter can be assured it will be given a chance to free it in the completion callback, and that the completion callback won't be called more than once to provoke the filter to free the memory more than once.
- The operations for which pre- and post-callbacks may be provided include the existing IRP_MJ_codes from IRP_MJ_CREATE to IRP_MJ_PNP, IRP_MJ codes created to represent fast I/O operations for which there is no IRP equivalent, and IRP_MJ codes created to represent FS filter operations. If future operating system versions add new IRP_MJ_ codes, existing filters will be unaffected, and will not receive any callbacks for IRP_MJ_ routines that did not exist when the filter was compiled. If a filter registers with an IRP_MJ_ code that the operating system does not recognize, FltRegisterFilter( )will return a special success status, and only call the callbacks for functions that exist in that version. If a filter does not want to continue to run if one or more callbacks will not be provided, the filter can call FltUnregisterFilter( ).
- Note that the callbacks for IRP_MJ_READ and IRP_MJ_WRITE will be invoked for IRP-based I/O and for fast I/O. The pre-callout for IRP_MJ_CREATE will not be passed contexts for the file or stream, as it is not yet determined at pre-create time what file or stream (if any) is going to be created. The post-callout for IRP_MJ_CLOSE will not be passed any contexts, as the system-internal structures with which they are associated are freed before the post-close routine is called. The pre-callbacks for IRP_MJ_CLEANUP and IRP_MJ_CLOSE must succeed and return FLT_PREOP_SUCCESS_WITH_CALLBACK or FLT_PREOP_SUCCESS_NO_CALLBACK.
- The post-operation callbacks have the potential to be called at DPC level, and therefore they should not wait for resources or mutexes, nor should they call any function that would wait. Note that routines such as FltSetFileContext( ) acquire resources and thus may not be called from post-operation callbacks.
- As described above, post callbacks return either FLT_POSTOP_STATUS_SUCCESS or FLT_POSTOP_MORE_PROCESSING_REQUIRED. Post-callbacks can be failed by setting an error code in the IoStatus, and in general the rule is that it is the filter's responsibility to undo what ever has occurred.
- In addition to dynamically registering filter instances, filter instances may be dynamically detached, whereby such a filter instance will no longer be called for any operations on that volume. Unloading a filter essentially means that its code is no longer in memory. This will most often be done at system shutdown time and when a new version of a filter is being installed without shutting the system down. Note that a filter instance can be detached even when there is outstanding I/O. In that case, the filter's completion routine or routines will be called for any outstanding I/O operations with the flag FLTFL_POST_OPERATION_DRAINING set. The fiter will not receive completion callbacks when those I/O operations actually complete. When a filter instance is detached, the system will call routines to free the filter's context, for outstanding contexts for files, streams, and stream file objects associated with that instance.
- As can be seen from the foregoing detailed description, there is provided a managed filter driver architecture that handles much of the I/O handling requirements, thereby facilitating simpler and more reliable filter drivers. The drivers may selectively register for only the I/O in which they are interested, improving efficiency. Dynamic load and unload, attach and detach are achieved. Other benefits include context management, including on file systems with multi-stream capabilities. The method and system thus provide significant advantages and benefits needed in contemporary computing.
- While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
Claims (18)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/344,258 US7779425B2 (en) | 2002-12-09 | 2006-01-30 | Managed file system filter model and architecture |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/315,384 US6993603B2 (en) | 2002-12-09 | 2002-12-09 | Managed file system filter model and architecture |
US11/344,258 US7779425B2 (en) | 2002-12-09 | 2006-01-30 | Managed file system filter model and architecture |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/315,384 Continuation US6993603B2 (en) | 2002-12-09 | 2002-12-09 | Managed file system filter model and architecture |
Publications (2)
Publication Number | Publication Date |
---|---|
US20060136460A1 true US20060136460A1 (en) | 2006-06-22 |
US7779425B2 US7779425B2 (en) | 2010-08-17 |
Family
ID=32325898
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/315,384 Expired - Lifetime US6993603B2 (en) | 2002-12-09 | 2002-12-09 | Managed file system filter model and architecture |
US11/344,258 Expired - Fee Related US7779425B2 (en) | 2002-12-09 | 2006-01-30 | Managed file system filter model and architecture |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/315,384 Expired - Lifetime US6993603B2 (en) | 2002-12-09 | 2002-12-09 | Managed file system filter model and architecture |
Country Status (10)
Country | Link |
---|---|
US (2) | US6993603B2 (en) |
EP (1) | EP1429247B1 (en) |
JP (1) | JP3974892B2 (en) |
KR (1) | KR100868410B1 (en) |
CN (1) | CN100504764C (en) |
AU (1) | AU2003266438B2 (en) |
BR (1) | BRPI0305401B1 (en) |
CA (1) | CA2450044C (en) |
MX (1) | MXPA03011280A (en) |
RU (1) | RU2335796C2 (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060053228A1 (en) * | 2004-09-03 | 2006-03-09 | Ophir Rachman | Method and apparatus for allowing sharing of streamable applications |
US20090204978A1 (en) * | 2008-02-07 | 2009-08-13 | Microsoft Corporation | Synchronizing split user-mode/kernel-mode device driver architecture |
WO2011059363A1 (en) * | 2009-11-16 | 2011-05-19 | Pilkin Vitaly Evgenievich | Method for identifying infected electronic files |
US20160364406A1 (en) * | 2015-06-10 | 2016-12-15 | International Business Machines Corporation | Integrating external services with a clustered file system |
US20190310883A1 (en) * | 2018-04-06 | 2019-10-10 | Didi Research America, Llc | Method and system for kernel routine callbacks |
US10742731B2 (en) | 2015-06-10 | 2020-08-11 | International Business Machines Corporation | Maintaining service configuration consistency across nodes of a clustered file system |
Families Citing this family (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US20050091389A1 (en) * | 2003-10-27 | 2005-04-28 | Qi Emily H. | Media access control architecture |
US7496565B2 (en) * | 2004-11-30 | 2009-02-24 | Microsoft Corporation | Method and system for maintaining namespace consistency with a file system |
KR100714682B1 (en) * | 2004-12-02 | 2007-05-04 | 삼성전자주식회사 | File system path processing device and method thereof |
US9639554B2 (en) * | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
EP1684151A1 (en) * | 2005-01-20 | 2006-07-26 | Grant Rothwell William | Computer protection against malware affection |
US7818608B2 (en) * | 2005-02-18 | 2010-10-19 | Microsoft Corporation | System and method for using a file system to automatically backup a file as a generational file |
US7523461B2 (en) * | 2005-07-01 | 2009-04-21 | Microsoft Corporation | Modification of logic in an application |
US7962731B2 (en) | 2005-10-20 | 2011-06-14 | Qualcomm Incorporated | Backing store buffer for the register save engine of a stacked register file |
US20070118559A1 (en) * | 2005-11-18 | 2007-05-24 | Microsoft Corporation | File system filters and transactions |
US20070299891A1 (en) * | 2006-06-26 | 2007-12-27 | Bellsouth Intellectual Property Corporation | Data back-up utility |
US20080005315A1 (en) * | 2006-06-29 | 2008-01-03 | Po-Ching Lin | Apparatus, system and method for stream-based data filtering |
US8560760B2 (en) * | 2007-01-31 | 2013-10-15 | Microsoft Corporation | Extending flash drive lifespan |
US7657572B2 (en) | 2007-03-06 | 2010-02-02 | Microsoft Corporation | Selectively utilizing a plurality of disparate solid state storage locations |
US7783677B2 (en) * | 2007-03-30 | 2010-08-24 | Microsoft Corporation | Tracking file system namespace changes during transactions |
US20090049459A1 (en) * | 2007-08-14 | 2009-02-19 | Microsoft Corporation | Dynamically converting symbolic links |
JP5046845B2 (en) * | 2007-10-15 | 2012-10-10 | 株式会社日立製作所 | Data update history storage device and data update history storage method |
US8136126B2 (en) * | 2008-01-31 | 2012-03-13 | International Business Machines Corporation | Overriding potential competing optimization algorithms within layers of device drivers |
US8181033B1 (en) * | 2008-07-01 | 2012-05-15 | Mcafee, Inc. | Data leakage prevention system, method, and computer program product for preventing a predefined type of operation on predetermined data |
US8495030B2 (en) * | 2011-01-06 | 2013-07-23 | International Business Machines Corporation | Records declaration filesystem monitoring |
US8234316B2 (en) * | 2008-09-30 | 2012-07-31 | Microsoft Corporation | Nested file system support |
JP2010140165A (en) * | 2008-12-10 | 2010-06-24 | Tokyo Electric Power Co Inc:The | Information processing device, method, and program as filter driver for monitoring |
JP5399094B2 (en) * | 2009-02-25 | 2014-01-29 | 株式会社日立情報通信エンジニアリング | A computer equipped with filter driver means for auxiliary storage device, filter driver program for auxiliary storage device, and recording medium for filter driver program for auxiliary storage device |
CN102054007B (en) * | 2009-11-10 | 2012-10-31 | 北大方正集团有限公司 | Searching method and searching device |
US9684573B2 (en) * | 2010-04-29 | 2017-06-20 | Veritas Technologies Llc | Dismounting a storage volume |
US20110283358A1 (en) * | 2010-05-17 | 2011-11-17 | Mcafee, Inc. | Method and system to detect malware that removes anti-virus file system filter driver from a device stack |
US8918874B2 (en) * | 2010-05-25 | 2014-12-23 | F-Secure Corporation | Malware scanning |
KR101174751B1 (en) * | 2010-09-27 | 2012-08-17 | 한국인터넷진흥원 | Malware auto-analysis system and method using kernel call-back mechanism |
CN102194079B (en) * | 2011-03-18 | 2013-09-11 | 北京思创银联科技股份有限公司 | File access filtering method |
CN102841785B (en) * | 2011-06-24 | 2015-10-14 | 北京奇虎科技有限公司 | A kind of method of file handle shutoff operation and device |
US8776094B2 (en) | 2011-08-11 | 2014-07-08 | Microsoft Corporation | Runtime system |
US8695021B2 (en) * | 2011-08-31 | 2014-04-08 | Microsoft Corporation | Projecting native application programming interfaces of an operating system into other programming languages |
US8516210B2 (en) * | 2011-12-21 | 2013-08-20 | Microsoft Corporation | Application consistent snapshots of a shared volume |
US20130304705A1 (en) * | 2012-05-11 | 2013-11-14 | Twin Peaks Software, Inc. | Mirror file system |
US9069572B2 (en) | 2012-07-27 | 2015-06-30 | Prolific Technology Inc. | Replacement of inbox driver with third party driver |
US9430548B1 (en) | 2012-09-25 | 2016-08-30 | Emc Corporation | Generating context tree data based on a tailored data model |
US9852140B1 (en) * | 2012-11-07 | 2017-12-26 | Axcient, Inc. | Efficient file replication |
TW201421264A (en) * | 2012-11-16 | 2014-06-01 | zong-yi Guo | Keyword file filtering system |
TWI488066B (en) * | 2012-12-27 | 2015-06-11 | Chunghwa Telecom Co Ltd | System and method to prevent confidential documents from being encrypted and delivered out |
CN103414555B (en) * | 2013-08-15 | 2016-08-10 | 成都卫士通信息产业股份有限公司 | The key management method that array is encrypted based on I/O block |
RU2584505C2 (en) * | 2014-04-18 | 2016-05-20 | Закрытое акционерное общество "Лаборатория Касперского" | System and method for filtering files to control applications |
US9507823B2 (en) * | 2014-06-18 | 2016-11-29 | Sap Se | Automated metadata lookup for legacy systems |
KR101699046B1 (en) * | 2014-08-25 | 2017-01-23 | (주)블루문소프트 | File Security system based on filter driver and method thereof |
US10635504B2 (en) | 2014-10-16 | 2020-04-28 | Microsoft Technology Licensing, Llc | API versioning independent of product releases |
TWI608379B (en) * | 2015-12-31 | 2017-12-11 | 玉山商業銀行股份有限公司 | Information management method, host device and system for data protection in accessing process |
US10515226B2 (en) * | 2016-11-21 | 2019-12-24 | Dell Products, L.P. | Systems and methods for protected local backup |
US10261925B2 (en) | 2017-06-23 | 2019-04-16 | Microsoft Technology Licensing, Llc | Enhanced techniques for detecting programming errors in device drivers |
CN107292196A (en) * | 2017-06-27 | 2017-10-24 | 北京华云网际科技有限公司 | The reading/writing method and device of I/O data |
US10824598B2 (en) * | 2018-08-07 | 2020-11-03 | Dell Products L.P. | Handling file commit and commit-delete operations in an overlay optimizer |
US10621130B1 (en) | 2018-10-08 | 2020-04-14 | Microsoft Technology Licensing, Llc | Ordering filter drivers in a device stack with filter levels |
CN110457899B (en) * | 2019-08-12 | 2021-06-01 | 北京无线电测量研究所 | Operating system protection system and method |
US11412005B2 (en) * | 2019-08-29 | 2022-08-09 | Juniper Networks, Inc. | Lawfully intercepting traffic for analysis based on an application identifier or a uniform resource locator (URL) associated with the traffic |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20010020245A1 (en) * | 2000-02-16 | 2001-09-06 | Microsoft Corporation | Method and system for deterministic ordering of software modules |
US6363400B1 (en) * | 1999-02-22 | 2002-03-26 | Starbase Corp. | Name space extension for an operating system |
US6389433B1 (en) * | 1999-07-16 | 2002-05-14 | Microsoft Corporation | Method and system for automatically merging files into a single instance store |
US6389427B1 (en) * | 1998-02-20 | 2002-05-14 | Redleaf Group, Inc. | File system performance enhancement |
US6611863B1 (en) * | 2000-06-05 | 2003-08-26 | Intel Corporation | Automatic device assignment through programmable device discovery for policy based network management |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000047952A (en) | 1998-07-27 | 2000-02-18 | Toshiba Corp | Network file server system and file managing method in the system |
CN1353830A (en) * | 1999-03-30 | 2002-06-12 | 松下电器产业株式会社 | Data processing system, data transmitting/receiving device, and recorded medium |
US7444317B2 (en) | 2002-06-28 | 2008-10-28 | Microsoft Corporation | System and method for managing file names for file system filter drivers |
KR100499611B1 (en) * | 2002-08-22 | 2005-07-05 | 엘지전자 주식회사 | Method and apparatus for managing power of computer system |
-
2002
- 2002-12-09 US US10/315,384 patent/US6993603B2/en not_active Expired - Lifetime
-
2003
- 2003-11-18 CA CA2450044A patent/CA2450044C/en not_active Expired - Fee Related
- 2003-12-03 AU AU2003266438A patent/AU2003266438B2/en not_active Ceased
- 2003-12-03 BR BRPI0305401A patent/BRPI0305401B1/en not_active IP Right Cessation
- 2003-12-05 MX MXPA03011280A patent/MXPA03011280A/en active IP Right Grant
- 2003-12-08 RU RU2003135656/09A patent/RU2335796C2/en not_active IP Right Cessation
- 2003-12-08 JP JP2003409683A patent/JP3974892B2/en not_active Expired - Fee Related
- 2003-12-08 KR KR1020030088524A patent/KR100868410B1/en active IP Right Grant
- 2003-12-09 EP EP03028234.7A patent/EP1429247B1/en not_active Expired - Lifetime
- 2003-12-09 CN CNB2003101225714A patent/CN100504764C/en not_active Expired - Fee Related
-
2006
- 2006-01-30 US US11/344,258 patent/US7779425B2/en not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6389427B1 (en) * | 1998-02-20 | 2002-05-14 | Redleaf Group, Inc. | File system performance enhancement |
US6363400B1 (en) * | 1999-02-22 | 2002-03-26 | Starbase Corp. | Name space extension for an operating system |
US6389433B1 (en) * | 1999-07-16 | 2002-05-14 | Microsoft Corporation | Method and system for automatically merging files into a single instance store |
US20010020245A1 (en) * | 2000-02-16 | 2001-09-06 | Microsoft Corporation | Method and system for deterministic ordering of software modules |
US6611863B1 (en) * | 2000-06-05 | 2003-08-26 | Intel Corporation | Automatic device assignment through programmable device discovery for policy based network management |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060053228A1 (en) * | 2004-09-03 | 2006-03-09 | Ophir Rachman | Method and apparatus for allowing sharing of streamable applications |
US9124653B2 (en) * | 2004-09-03 | 2015-09-01 | Symantec Corporation | Method and apparatus for allowing sharing of streamable applications |
US20090204978A1 (en) * | 2008-02-07 | 2009-08-13 | Microsoft Corporation | Synchronizing split user-mode/kernel-mode device driver architecture |
US8434098B2 (en) * | 2008-02-07 | 2013-04-30 | Microsoft Corporation | Synchronizing split user-mode/kernel-mode device driver architecture |
WO2011059363A1 (en) * | 2009-11-16 | 2011-05-19 | Pilkin Vitaly Evgenievich | Method for identifying infected electronic files |
US9940213B2 (en) * | 2015-06-10 | 2018-04-10 | International Business Machines Corporation | Integrating external services with a clustered file system |
US20160364406A1 (en) * | 2015-06-10 | 2016-12-15 | International Business Machines Corporation | Integrating external services with a clustered file system |
US20180157570A1 (en) * | 2015-06-10 | 2018-06-07 | International Business Machines Corporation | Integrating external services with a clustered file system |
US10592373B2 (en) * | 2015-06-10 | 2020-03-17 | International Business Machines Corporation | Integrating external services with a clustered file system |
US10742731B2 (en) | 2015-06-10 | 2020-08-11 | International Business Machines Corporation | Maintaining service configuration consistency across nodes of a clustered file system |
US20190310883A1 (en) * | 2018-04-06 | 2019-10-10 | Didi Research America, Llc | Method and system for kernel routine callbacks |
WO2019194873A1 (en) * | 2018-04-06 | 2019-10-10 | Didi Research America, Llc | Method and system for kernel routine callbacks |
CN111919198A (en) * | 2018-04-06 | 2020-11-10 | 北京嘀嘀无限科技发展有限公司 | Kernel function callback method and system |
US11106491B2 (en) * | 2018-04-06 | 2021-08-31 | Beijing Didi Infinity Technology And Development Co., Ltd. | Method and system for kernel routine callbacks |
Also Published As
Publication number | Publication date |
---|---|
CA2450044C (en) | 2012-03-27 |
BRPI0305401B1 (en) | 2016-07-19 |
EP1429247A2 (en) | 2004-06-16 |
CN1508679A (en) | 2004-06-30 |
CN100504764C (en) | 2009-06-24 |
US7779425B2 (en) | 2010-08-17 |
CA2450044A1 (en) | 2004-06-09 |
MXPA03011280A (en) | 2004-09-10 |
AU2003266438B2 (en) | 2009-06-11 |
EP1429247B1 (en) | 2013-06-19 |
RU2335796C2 (en) | 2008-10-10 |
AU2003266438A1 (en) | 2004-06-24 |
JP3974892B2 (en) | 2007-09-12 |
US6993603B2 (en) | 2006-01-31 |
US20040111389A1 (en) | 2004-06-10 |
JP2004192648A (en) | 2004-07-08 |
RU2003135656A (en) | 2005-06-10 |
KR100868410B1 (en) | 2008-11-11 |
BR0305401A (en) | 2004-08-31 |
EP1429247A3 (en) | 2007-05-16 |
KR20040050855A (en) | 2004-06-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7779425B2 (en) | Managed file system filter model and architecture | |
Russinovich et al. | Windows internals, part 2 | |
US8983988B2 (en) | Centralized management of virtual machines | |
US7243198B2 (en) | Method and system for transporting data content on a storage area network | |
US7676508B2 (en) | Method and system for recording and replaying input-output requests issued by a user-mode program | |
US8539481B2 (en) | Using virtual hierarchies to build alternative namespaces | |
US20060253501A1 (en) | Fast and reliable synchronization of file system directories | |
US20060190469A1 (en) | Serialization of file system item(s) and associated entity(ies) | |
US20030005168A1 (en) | System and method for auditing system call events with system call wrappers | |
US5931925A (en) | System and method for efficiently transferring datastreams in a multimedia system | |
EP1622062A2 (en) | Framework for a security system | |
US20030208501A1 (en) | FAT file system in Palm OS computer | |
US20060155784A1 (en) | Method and system of previewing a volume revert operation | |
US7421560B2 (en) | Method and system of computing quota usage | |
US7272712B1 (en) | Data structure and method for managing modules associated with a kernel | |
US20090307193A1 (en) | Testing File System Semantic Parity | |
Miroshnichenko | Data management API: the standard and implementation experiences | |
Bushnell et al. | The GNU Hurd Reference Manual | |
Gedara et al. | Exploration and comparison of Win32 API to improve data usage control | |
SEM | BCA 306 LINUX ENVIRONMENT | |
Stangel | A prototype implementation of a virtual file system | |
Guide | INFORMIX-OnLine Dynamic Server™ | |
Cabrera et al. | Cover Feature |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PUDIPEDDI, RAVISANKAR;BROWN, EILEEN C.;CHRISTIANSEN, NEAL;AND OTHERS;REEL/FRAME:018244/0810 Effective date: 20021209 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
CC | Certificate of correction | ||
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034543/0001 Effective date: 20141014 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552) Year of fee payment: 8 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20220817 |