Microsoft Technology Licensing, LLC

Craig Ashley Barkhouse

Neal Robert Christiansen

Sarosh Cyrus Havewala

Ping Xie

Michael John Novak

Daniel Chan

John D Slingwine

Ravisankar V Pudipeddi

John Andrew Starks

Scott A Brender

Chandra Kumar Konamki Vijayamuneeswaralu

Sven Groot

Lei Shi

Tyler Kien Beam

Anshul Rawat

Mohammed Samji

Raju Jain

David B Perry

Robert Paul St Pierre

Kiran Kumar G Bangalore

Srinivasan Malayala

Lane Haury

Thiago Sigrist

Sripresanna Sripresanna

Mohammed Amirali Samji

David Ben Perry

Described herein are technologies that provide an element of security related to file system operations. Individual nodes in a file system, such as a directory or a file, can be associated with information that describes how to handle letter case when a file name included in a file system operation request is used to locate a file in the file system. For example, a case sensitive designation associated with a directory can require a case sensitive match between a file name included in a request and a file name included in the directory, in order to perform the requested file system operation. In another example, a case preferring designation associated with a directory first checks for a case sensitive match between file names. If a case sensitive match does not exist, then a case insensitive match between the file names can be used to perform the requested file system operation.

Techniques for handling letter case in file systems

A file system executing on a computing device may store a placeholder for a file on secondary storage of the computing device. The placeholder may comprise a sparse data stream containing none or some of the data of the file and information which enables the remotely stored data of the file to be retrieved from the network. As some or all of the data for the file is being stored remotely, the computing device may rely on a storage virtualization provider to create metadata for the file. Thus, the file system executing on the computing device may receive, from the storage virtualization provider, a request to store metadata associated with the file. In response to this request, the file system may store the metadata as a Binary Large Object (BLOB) in a secondary data stream of the placeholder for the file.

Metadata storage for placeholders in a storage virtualization system

Storage virtualization techniques allow files and directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the files are stored locally&#x2014;even though the data of those files and directories may not be resident on the local computing device. That is, the contents of files and directories that may exist in the cloud look and behave as if they were stored locally on a computing device. The level of hydration of placeholders may be monitored and operations may be performed to reduce the impact of excessive hydration on the resources of the computing device.

Preventing excessive hydration in a storage virtualization system

Storage virtualization techniques allow directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the directories are stored locally&#x2014;even though the data of those directories may not be resident on the local computing device. That is, the contents of directories that may exist in the cloud look and behave as if they were stored locally on a computing device.

Storage virtualization for directories

Determination logic for a cloud content states framework is described herein. In implementations, a framework is configured to perform operations for management of cloud content files at the computing device on behalf of cloud storage providers. Determination logic for the framework is utilized to make state determinations in dependence upon a defined set of file sync properties. The framework operates to make assessments of the file sync properties and set states for files in accordance with the assessments. In implementations, file sync properties are related to corresponding states through a mapping data structure that maps file sync property values to different states and enables look-ups of states based on property values. The framework utilizes and references the mapping data structure to match file sync properties identified for cloud content files to corresponding states and then set states for the cloud content files accordingly.

Cloud content states determination logic

The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.

Controlling reparse behavior associated with an intermediate directory

Processing for file system volume error detection and processing for resultant error correction are separated to support system availability and user satisfaction. File system volumes for storing data structures are proactively scanned while the volumes remain online to search for errors or corruptions thereon. Found errors are scheduled to be corrected, i.e., spot corrected, dependent on the severity of the identified errors, error correction scheduling and/or at the determination of a file system administrator and/or user, to assist in maintaining minimal user and file system impact. When spot correction is initialized, one file system volume at a time is taken offline for correction. Spot correction verifies prior logged corruptions for the offline volume, and if independently verified, attempts to correct the prior noted corruptions. Volumes are retained offline only for the time necessary to verify and attempt to correct prior noted volume corruptions.

Proactive error scan and isolated error correction

Perceived corruptions encountered on file system volumes, and which cannot be initially remedied online, are processed to verify whether they are true, existing volume data structure corruptions or, alternatively, false positives. Upon the verification of one or more of a volume's corruptions, error scanning is performed to check for, and attempt to remedy online, all the existing corruptions on the volume. Subsequent to error scanning processing, if one or more verified corruptions continue to exist on a file system volume, at file system boot up time spot corruption correction is performed to attempt to remedy the existing, verified corruptions on the volume. Spot corruption correction is performed to attempt to correct verified data structure corruptions on a volume of the file system while the volume is maintained offline for the time necessary to attempt to correct its prior identified corruptions.

File system resiliency management

Data structure errors, or corruptions, identified during, e.g., normal computing device system processing, file system processing or user access processing, are verified prior to the file system identifying the error for offline correction or notifying the user or system administrator a data structure error exists. Identified data structure corruptions are verified while the file system volumes are maintained online and otherwise accessible to other processing tasks and user access. Verified data structure corruptions are logged for further corrective processing. Data structure corruptions that cannot be verified, i.e., false positives, are not further processed and are not identified to file system administrators or users as corruptions, freeing the file system to concentrate on normal processing and true, verifiable errors.

Online fault verification in a file system

Growing community of inventors

Duvall, WA, United States of America

Craig Ashley Barkhouse