Microsoft Technology Licensing, LLC

Matthew Stuart Garson

Neal Robert Christiansen

Sarosh Cyrus Havewala

Thomas Jay Miller

Chesong Lee

David Matthew Kruse

Karan Mehra

Mathew George

Ravinder S Thind

Darwin Ou-Yang

Christian Gregory Allred

Hui Li

Daniel Edward Lovinger

Aspects of the subject matter described herein relate to querying and repairing data. In aspects, a component may detect that data on storage has become corrupted. In response, the component may request data from one or more redundant copies of the data and may determine which of the redundant copies, if any, are not corrupted. If a non-corrupted copy is found, the component may send a request that the corrupted data be repaired and may identify the non-corrupted copy to use to repair the corrupted data.

Querying and repairing data

Current file systems may implement opportunistic locks on files that allow clients to locally cache file data, while promoting data consistency when multiple clients read/write the same file. Unfortunately, when a client locally caches directory content of a directory, the file system may lack a mechanism for notifying the client of changes to the directory that would render the cached directory content 'stale'. Accordingly, one or more systems and/or techniques for managing a directory oplock are disclosed herein. A directory oplock may be generated based upon an oplock request comprising a first target key and a first parent key. Subsequent access requests for access to the directory or objects therein may be compared with the directory oplock to determine whether to break the directory oplock, and notify the client (e.g., directory oplock is broken if the client submitting the access request is different than the client owning the directory oplock).

Directory oplock

In accordance with one or more aspects of the application-managed file versioning, a request to store a new version of a file is received from an application, the request having been generated by the application. A filename for the new version of the file is generated, derived from a standardized naming convention. The filename includes a first portion having at least a portion of a name of the file, and a second portion having data indicating that the new version of the file is a version of the file. A set of application programming interfaces (APIs) can be exposed that allow the application to manage file versions, such as creating a new version of a file, identifying one or more versions of the file, listing one or more versions of the file, and deleting one or more versions of the file.

Application-managed file versioning

Embodiments include a file system data structure and file system recognition APIs that may allow an operating system to identify a partition of a storage device as having a valid file system, even if the operating system does not know how to access the file system a priori. File systems can implement these data structures in a standardized, known location within a partition on the storage device such that an operating system may use APIs or other functions to examine the known location for the presence of these data structures. Information on how to interpret the data structure may be obtained using a network or other source.

File system recognition structure

Growing community of inventors

Seattle, WA, United States of America

Matthew Stuart Garson