APVFS Virtual file system library

Quick Intro:

The APVFS library uses a virtual file systems mechanism similar to the one used in Midnight Commander, Dos Navigator, FAR or almost any modern file manager. It allows the user to access data stored in archives as if they were ordinary files.
On-the-fly generated files that exist only in memory are also supported.
The library is built on top of APR library.

_{Figure 1. APVFS design.}

Design notes:

The APVFS API is identical to APR's file API calls. All operations are based on supplied filename to particular function call. The desired file system can be loaded as dso  at runtime.

• APVFS Core:
  That's the core of the APVFS managing things.
  • Reference volume cache:
    Caches the volumes for file systems that support volume concept. The cached volume can be ZIP archive or a connection to external database for example. The caching is reference counted, meaning that when all files are closed the volume is closed too.
  • Volume manager:
    Manages volumes
  • Type mapper:
    Resolves the protocols and protocol stack
• Module loader:
  Loads the file systems as needed depending on desired protocol. The modules can be either builtin or dynamically loaded as dso's. The module name is resolved depending on protocol and if bz2: protocol is required, the module loader will look for mvfs_bz2.so
  The module api is provided here: apv_lib.h.
• API:
  API is based on APR file API to allow easy transition from existing local file system to the virtual.
  Here is the header file showing API functions: apv_file_io.h

Location:
Location is the basic element that distinguishes file system. It consists of tree parts and is managed by Type mapper.
The basic syntax of the location is: [protocol][address][anchor].

• Protocol
  Type mapper can recognize if it is able to open a file by checking its protocol.
  Examples are "http:", "file:" or "ftp:". If the protocol is not specified then the default file: system is used.
• Address
  Address is the name of the file within the protocol. In "http://www.apache.org/index.html" the address is
  "//www.apache.org/index.html". Address meaning depends on the provided protocol and it can be the url like in the upper example or the local (plain) file.
• Anchor
  An anchor is optional and is used on compound file systems like ZIP archives and form nesting protocols. In "zip:/usr/local/archive.zip#index.html" the anchor is "index.htm", and that means that the opened file will be index.html in the archive located at /usr/local/archive.zip.

Nesting Protocols:

Anchors are used for nesting protocols, and the current design limits to the protocol nesting is two.
The opened nested protocols are unidirectional (either read or write)

Few examples of nested protocols:

apv_file_open(&f, "gz:#bucket:0xAABBCCDD", APR_READ, ...)

The top protocol in this example is gz, and this will have the following meaning:
The bucket brigade with in memory address 0xAABBCCDD will be used as input stream for gz inflate, meaning that the apv_file_read(f, ...) returned data will be inflated data from the supplied bucket brigade.
The write function apv_file_write(f, ...) will in that case, write deflated data to specified bucket brigade, creating new buckets as needed.

Using slightly different syntax:
apv_file_open(&f, "gz:/home/arcive.gz#bucket:0xAABBCCDD", APR_READ, ...)

This syntax has no real meaning cause the top protocol in this example is again gz, but with provided real file, meaning that the anchor will be disregarded because we already have two protocols in stack (the gz and the local filesystem).



 

Designer:
Mladen Turk,
Zagreb, Croatia