Microsoft Technology Licensing, LLC

Microsoft Corporation

Eileen C Brown

Neal Robert Christiansen

Ravisankar V Pudipeddi

David Golds

Ravinder S Thind

Mark Joseph Zbikowski

Brian Kenneth Dewey

David Matthew Kruse

James T Pinkerton

Keith Stuart Kaplan

Garret Buban

Rohan Kumar

Thomas Ewan Jolly

Prashanth Prahalad

Vikrant H Desai

Neal Christiansen

David P Golds

Aspects of the subject matter described herein relate to client-side caching. In aspects, when a client receives a request for data that is located on a remote server, the client first checks a local cache to see if the data is stored in the local cache. If the data is not stored in the local cache, the client may check a peer cache to see if the data is stored in the peer cache. If the data is not stored in the peer cache, the client obtains the data from the remote server, caches it locally, and publishes to the peer cache that the client has a copy of the data.

Populating and using caches in client-side caching

Systems and methods that create a virtual name space of Universal Naming Convention (UNC) over a local file system (e.g., drive letter based names), via employing a UNC provider and filter arrangement that changes a name in the file object to reparse it to a volume where the local file exists. A name in the file object is changed to a local name (e.g., morphed name); subsequently reparsed and forwarded to a Name Space Owner component (NSO). As such, a request can originate from a UNC stack and reparsed on the local stack. The name space is presented to an application in UNC format, while the underlying file write occur in the file system.

Virtual universal naming convention name space over local file system

A model in which filter drivers are managed to receive callbacks for I/O requests in which the filter drivers have registered an interest. Per-volume instances of filter drivers register with a filter manager for pre-callbacks (for I/O to the file system) and post-callbacks (for I/O from the file system), and identify which I/O requests (e.g., create, read, write) they are registering to receive callbacks. The filter manager orders the instances for callbacks. When an I/O request is received, the filter manager converts the I/O request to callback data and calls the interested filters in the callback order, whereby the filter instances can process the I/O data. As the request returns from the file system, filters desiring post callbacks are called in the reverse order. Efficient context management for the filters and other functions, such as non-reentrant file I/O, are also provided by the model.

Managed file system filter model and architecture

Described is a method and system that manages filenames for filter drivers in a file system. The present invention includes a filter manager that handles filename queries from the filter drivers. The filter manager returns a pointer to the requesting filter driver that points to a filename information structure corresponding to the type of filename requested. The filter manager also manages a cache of filename information structures that include information that can be shared among the various filter drivers, amortizing the filename queries for filter drivers. The caching functionality of the filter manager increases the efficiency and reduces the overhead of filename queries within the file system by reducing the number of filename operations required for a file system filter driver to retrieve a desired portion of the filename.

System and method for managing file names for file system filter drivers

The invention provides a system and method for dynamically unloading file system filters in a stacked-call-back model where filters are stacked one on top of the other to form a filter stack. A filter manager keeps track of the progress of each I/O operation and calls each filter in turn with the filter returning after it has completed processing the given operation. The filter manager dynamically unloads a filter (or an instance of a filter) that is positioned at any position in the filter stack in a reasonable amount of time while I/O operations are actively being processed. The filter/filter instance can be unloaded with outstanding I/O operations on the filter either hosted by the filter or pended by other filters. I/O operations are canceled, completed or drained in order to unload the filter or filter instance. A filter may veto the unloading of the filter.

Method and apparatus for dynamically unloading file system filters

A method and system for ordering software modules in a guaranteed order for execution. Unique values are statically assigned to software modules (e.g., filter drivers) when fully developed. Each module's assigned value determines its relative position to other modules in a stack or other arrangement, fixing the execution order for any set of filter drivers. Static values may comprise floating-point numbers, whereby each new software module may be assigned a number that enables positioning it between any two existing software modules. For example, filter drivers may be generally classified and assigned values in a range according to type. Drivers of the same type may be ordered within their general range to guarantee one possible ordering. A filter manager architecture is described, in which filter drivers register with a manager for relevant file system I/O operations. The manager calls appropriately registered filter drivers in an order based on their assigned numbers.

Method and system for deterministic ordering of software modules

Growing community of inventors

Seattle, WA, United States of America

Eileen C Brown