Universal File System

The Universal File System is a concept used in the IO and IO.FileSystem namespaces that generalizes all file systems into one consistent API. Similarly to the Unix concept of files, it tries to expose many devices and resources using a system addressed by the URI of a particular resource.

This system was created with a couple of points in mind. First, there should be a minimum of static methods required to use in order to work with files in the UFS, using objects instead wherever possible. This makes the system easy to use in remoting. Second, the system should be maximally extensible by system-specific APIs, but generic at the same time. Ideally, anything should be able to be done with a resource without knowing the specific file system it comes from.

The core class of the UFS is the ResourceInfo class (inherit from MarshalByRefObject if you want remoting support). This class holds information about a file in any file system, similar to the FileInfo class in the BCL. Files are represented by a single URI specifiying the file system in the scheme part, and the path and other information in the other components. When obtaining information from a ResourceInfo, its respective file system is reponsible for locating the right file and performing the requested action.

An example is the file scheme specifying files in the Win32 file system. This is also the default system when specifying the location as string and not as an URI. This file systems holds all DOS, UNC and NTFS paths accessible via the standard system functions (mostly via functions from kernel32.dll, because the standard .NET classes don't allow working with non-file objects). For UNC paths, the target computer is specified in the host section of the URI.

Another notable scheme is the shell scheme. This corresponds partially to the shell namespace in Windows Explorer, allowing to access virtual files and folders via the UFS API. An example path is shell:Desktop which points to the desktop of the current user. Other locations are the Computer, Recycle Bin, or Documents folders, with each of them able to be browsed and manipulated using the standard API.

All file systems should also be aware of links. If a file in the file system is a link, i.e. a special file pointing to another file, the ResourceFlags enum specifies whether the links should be handled as standard files, or resolved for file operations. In case of the Win32 system, standard NTFS reparse points (symbolic links and directory junctions) are handled as links, while for the Shell file system, standard shortcuts (.lnk, .pif, and .url) or any other system-defined shortcut files are resolved and treated as links.

However, the ResourceInfo class is not enough. Its major disadvantage is that it is defined to only hold its file system and the path, but it cannot open the file for applying a batch of operations directly, because it needs to parse the path any time the file is accessed. For this case, the ResourceHandle class is the second half of the user API. The ResourceHandle class derives all methods from the ResourceInfo class, but allows each file system to inherit it and implement these methods in its own way, without relying on the actual file system object.

For example, a standard Win32 HANDLE is used as a ResourceHandle, or the PIDL of a file in the Shell namespace (because the Shell COM API doesn't really have special objects for holding a file handle, only a folder and the relative PIDL).