File systems driver design guide

This section of the WDK provides conceptual information related to file systems and filter drivers. For reference pages that describe the interfaces your driver can implement or call, see the File System Programming Reference.

File systems

File systems in Windows are implemented as file system drivers working above the storage system.

Every system-supplied file system in Windows is designed to provide reliable data storage with varying features to meet the user’s requirements. Standard file systems available in Windows include NTFS, ExFAT, UDF, and FAT32. A comparison of features for each of these file systems is shown in File System Functionality Comparison. Additionally, the Resilient File System (ReFS), available on Windows Server 2012 and later versions, offers scalable large volume support and the ability to detect and correct data corruption on disk.

Developing a new file system driver is almost always unnecessary, and requirements/specifications for new file system drivers are not predictable. To that end, this design guide does not cover file system development. If you do need to develop a new file system driver beyond those available in Windows, sample code is available as a model (see below).

File system filter drivers

A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. Examples of filter drivers include:

• Anti-virus filters
• Backup agents
• Encryption products

Filter driver developers use the system-supplied Filter Manager, which provides a framework for developing filter drivers without having to manage all the complexities of file I/O. The Filter Manager simplifies the development of third-party filter drivers and solves many of the problems with the legacy filter driver model, such as the ability to control load order through an assigned altitude.

File system and filter sample code

A number of Windows driver samples are available, including samples for file system development and file system filter driver development. See Windows driver samples for a complete list.

File system filter driver certification

Certification information for File Systems and File System Filter Drivers is found in the Windows Hardware Lab Kit (HLK). Tests for File Systems and File System Filter Drivers are found in the Filter.Driver category of the HCK.

Additional resources

Along with this documentation and the sample code mentioned above, OSR offers a variety of resources for file system filter development, including seminars and community discussion forums such as the NTFDS forum.

File System Programming Guide

About Files and Directories

The file system is an important part of any operating system. After all, it’s where users keep their stuff. The organization of the file system plays an important role in helping the user find files. The organization also makes it easier for apps and the system itself to find and access the resources they need to support the user.

This document is intended for developers who are writing software for macOS, iOS, and iCloud. It shows you how to use the system interfaces to access files and directories and how to move files to and from iCloud. This document also provides guidance on how best to work with files, and it shows you where you should be placing any new files you create.

Important: When you adopt App Sandbox in your macOS app, the behavior of many file system features changes. For example, to obtain access to locations outside of your app’s container directory, you must request appropriate entitlements. To obtain persistent access to a file system resource, you must employ the security-scoped bookmark features of the NSURL class or the CFURLRef opaque type. There are changes to the location of app support files (which are relative to your container rather than to the user’s home folder) and to the behavior of Open and Save dialogs (which are presented by the macOS security technology, Powerbox, not AppKit). For details on all these changes, read App Sandbox Design Guide.

At a Glance

To effectively use the file system, you must know what to expect from the file system and which technologies are available for accessing it.

The File System Imposes a Specific Organization

The file systems in iOS and macOS are structured to help keep files organized, both for the user and for apps. From the perspective of your code, a well-organized file system makes it easier to locate files your app needs. Of course, you also need to know where you should put any files you create.

Access Files Safely

On a multiuser system like macOS, it is possible that more than one app may attempt to read or write a file at the same time as another app is using it. The NSFileCoordinator and NSFilePresenter classes allow you to maintain file integrity and ensure that if files are made available to other apps (for example, emailing the current TextEdit document) that the most current version is sent.

How You Access a File Depends on the File Type

Different files require different treatments by your code. For file formats defined by your app, you might read the contents as a binary stream of bytes. For more common file formats, though, iOS and macOS provide higher-level support that make reading and writing those files easier.

System Interfaces Help You Locate and Manage Your Files

Hard-coded pathnames are fragile and liable to break over time, so the system provides interfaces that search for files in well-known locations. Using these interfaces makes your code more robust and future proof, ensuring that regardless of where files move to, you can still find them.

Users Interact with Files Using the Standard System Panels

For files that the user creates and manages, your code can use the standard Open and Save panels to ask for the locations of those files. The standard panels present the user with a navigable version of the file system that matches what the Finder presents. You can use these panels without customization, modify the default behavior, or augment them with your own custom content. Even sandboxed apps can use the panels to access files because they work with the underlying security layer to allow exceptions for files outside of your sandbox that the user explicitly chooses.

Read and Write Files Asynchronously

Because file operations require accessing a disk or network server, you should always access files from a secondary thread of your app. Some of the technologies for reading and writing files run asynchronously without you having to do anything, while others require you to provide your own execution context. All of the technologies do essentially the same thing but offer different levels of simplicity and flexibility.

As you read and write files, you should also use file coordinators to ensure that any actions you take on a file do not cause problems for other apps that care about the file.

Move, Copy, Delete, and Manage Files Like the Finder

The system interfaces support all of the same types of behaviors that the Finder supports and many more. You can move, copy, create, and delete files and directories just like the user can. Using the programmatic interfaces, you can also iterate through the contents of directories and work with invisible files much more efficiently. More importantly, most of the work can be done asynchronously to avoid blocking your app’s main thread.

Optimize Your File-Related Operations

The file system is one of the slowest parts of a computer so writing efficient code is important. Optimizing your file-system code is about minimizing the work you do and making sure that the operations you do perform are done efficiently.

Relevant chapter: Performance Tips

See Also

For information about more advanced file-system tasks that you can perform, see File System Advanced Programming Topics.

Copyright © 2018 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2018-04-09