File server extensions overview in File server extensions

A file server extension is a library that allows the functionality of a file server logical drive and its corresponding file system to be extended or modified.

This document provides an overview of the file server extension architecture, and of the APIs that allows file server extensions to be developed and used.

The file server uses libraries called file systems, which implement support for particular file system formats, such as FAT and LFFS. These file system libraries in turn make calls to the media sub-system, which provides device drivers that handles interaction with the actual storage hardware.

A file server extension is an additional layer that intercepts all calls from a file system to the media sub-system, as shown below:

File server extension architecture

All calls to the media sub-system from a mounted file system go through a "proxy" drive interface provided by the loaded extension (or extensions), before the call is passed on to the media sub-system interface.

An extension has the same lifetime as its corresponding file system object. This is usually a CMountCB object but can also be a subsession object (for example CFileCB). On removable drives, if a mount with an extension is destroyed when the media is removed, then when the same media is reinserted, the mount object and extension should be created at the same time.

Extensions can be referred to as being primary or secondary:

An extension is called primary if it is required for the file system to be used. Such extensions must be mounted before or at the same time as a file system is mounted on a drive. This can be done by modifying the initial mounting of the local file system in the base startup component, EStart. The filesystem mounted on the drive must be dismounted before a primary extension can be dismounted.

Only one primary extension is permitted to be mounted on a drive at a time.
Secondary extensions can be added after a file system is mounted. The maximum number of extensions allowed is two.

When two extensions are loaded, calls are passed through both extensions in turn. This is referred to as chaining. The order of chaining is determined by the order that extensions are mounted on the drive. The extension mounted first is closest to the media sub-system interface. Therefore a primary extension is always closest to the media sub-system interface.

The following are the key classes for the API:

Class Name	Description
`RFs`	Client access to a file server session, used to load and mount an extension. Use `RFs::AddExtension()` to load an extension, `RFs::DismountExtension()` to dismount an extension, and `RFs::RemoveExtension()` to remove an extension.
`CBaseExtProxyDrive`	This class defines virtual functions that are called by the file system to handle requests for such functions as reading and writing data from the drive. An extension DLL must implement a class derived from this interface to provide its functionality.
`CProxyDrive`	Interface between a local file system and a media subsystem. This is the base class for `CBaseExtProxyDrive`.
`CProxyDriveFactory`	Each extension DLL must implement a factory class that is responsible for creating proxy driver objects. This is done by implementing a class derived from `CProxyDriveFactory`.

Symbian OS uses a file server extension to implement its Flash Transition Layer (FTL) that allows a FAT file system to run on a NAND flash device. Because this layer is not needed when using FAT on a RAM disk or a MultiMediaCard, it is not necessary to add this functionality to the FAT file system itself. So the FTL is implemented as a file server extension and is only used on NAND local drives.

File Server Extensions overview

Purpose

Architectural relationships

API summary

Typical uses