Virtual File Systems can be separated into two classes:
- The file systems that store the files (let's call them Maintainers)
- The file systems that redirect file operation requests (let's call them Redirectors)
Maintainers implement an actual file system, i.e. they maintain some storage where they put file data. Redirectors don't maintain a storage, but redirect the file operation requests to the other file system.
No file system can be self-containing, i.e. it must call some external API functions to read or write the data to the media.
Maintainers read or write the logical blocks that don't represent the files. One can think about such blocks as being the sectors of the disk drive or being the blocks of the flash memory media. Maintainers perform read/write operations by calling some file system API or network API or by reading or writing the data blocks to memory (which was previously allocated with some API). But in all cases, they read or write the blocks of generic data, not associated with some particular file in the virtual file system.
Redirectors, on the other hand, forward the requests to the other (underlying) file system via file system API or network API (for network file systems). With minor exceptions, such requests are related to some particular entry (volume, directory or file) in the virtual file system. Redirectors can perform some pre-processing or post-processing of the requests, or they just forward the requests without any processing.
For example of a Redirector you can take a look at Callback File System (our other product).
Solid File System is a Maintainer. It maintains a file system structure inside of the storage. SolFS engine calls OS file management API to read or write the pages (sectors) from/to the storage file, stored on the actual disk. Besides actual writing of the pages to the storage file, SolFS supports so-called callback mode. In callback mode SolFS does not use OS file management API functions. Instead it calls the application-defined callback functions to read or write the pages from/to the storage. The application needs to implement all callback functions required to manipulate the storage and read/write the pages. Callback mode can be used to keep the storage in memory or somewhere across the network or in the database records.
When the application callback functions are called, they work only with the pages. These pages are not related in any way to the files or directories being stored inside of SolFS volume. You should treat the pages as the raw disk data.
SolFS architecture is unique as it supports dynamic sizing of the storage, where the file data is kept. The file system can work in fixed and resizeable modes. In resizeable mode SolFS automatically resizes the storage size as needed. When you implement the callbacks, you will need to implement and handle correctly OnFileGetSize and OnFileSetSize callbacks/events.
You start working in callback mode by defining the callback functions (delegates, event handlers) and telling SolFS to use those functions. After that you open the storage (using Open method or special form of class constructor depending on the SolFS API you use). Opening of the storage involves the operations of getting access to the storage media (OnFileOpen) and reading the information about the file system from the storage (OnFileSeek and OnFileRead). The storage is opened ONLY after the open operation is complete, i.e. when execution of the Open method or class constructor is completed. You should not expect the storage to be opened when OnFileOpen, OnFileSeek or OnFileRead callback function is called. In OnFileOpen callback function you can set some file handle (or other handle that will be used to access the underlying storage later), and this handle will be passed to other callback functions later.
After the storage is opened, you use it as you would do normally (i.e. not in callback mode).