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.
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.
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].
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).