[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The main `VFS.Mount.' section describes the layout of the "virtual" file system. Imagine a clean disk drive onto which you start to create directories by making links to existing "real" directories and archive (`.zip') files. An archive is treated exactly like a subdirectory; you even can link one "virtual directory" to several "real" paths and archives; however if you write files they will be written to the first directory or archive in list.
This section contains a list of virtual-to-real path mappings. The local name of the keys in the `VFS.Mount.' section define the virtual directory, and the values define the real paths, which can represent a list of physical directories and ZIP archives. The path lists should be separated by commas (,), so commas cannot be used in directory names. This should not be much of a restriction, but if it is for a particular application, change `VFS_PATH_DIVIDER' macro in `vfs.cpp'.
The VFS.Mount.
section usually makes heavy use of variable data since
most operating systems have different pathname semantics and syntax. The
"common denominator" that VFS emulates is a Unix-like filesystem. To
include the value of a variable in a VFS path use the
`$(variable-name)' construct. In the case where
`variable-name' consists of a single letter, you can omit the
parentheses, as in $variable-name
(for example `$A').
Variables that are defined in the environment override those defined in this file. For example, the `$HOME' environment variable is set in all Unixes, but is undefined in many other operating systems. They can define their own values for these variables in system-dependent sections, but if the user defines the `$HOME' environment variable it will always override the one from this file. You also can refer the variables in the following way: `$(var:expr)' which means "use the contents of `var' if `var' is set (usually in environment), or use `expr' if not". This can be used for more complex expressions, for example:
$(HOME:$(HOMEDIR:$(HOMEPATH:/home))) |
This expression means "take the value of the `$HOME' variable; if it is not set, use the contents of `$HOMEDIR'; if it is also not set, use `$HOMEPATH'; and if none are set, use the literal string `/home' as the resulting value.
The VFS class defines a variable called `/' that contains the path delimiter for the current operating system (i.e. `/' for Unix, `\' for Windows/DOS, and `:' for Macintosh). You reference this variable by writing `$/' rather than using the "real-world" delimiters `/', `\', or `:'.
The following is an example VFS configuration file.
Assume we wrote a game with three levels; the game is located on CD-ROM and we want to be able to release patches in the future which will replace several files from level archives (each level is presumed to be placed in a separate ZIP archive on either CD-ROM or cached on the hard drive). Additionally, we will add a link to user's home directory (something somewhat vaguely defined on non-Unix platforms) so that game can store the user's settings into the file `~/game.profile'.
Note that in this example many of the options in the real `vfs.cfg' are omitted. So you should not take this example for your game, because one of the libraries or plug-in modules you use may require a mapping that is not listed here. This example is only intended to understand the concept:
; The following variables should be defined either in ; the environment or in system-dependent sections: ; ; $. - The current directory. ; $@ - The directory into which CS has been installed. This is ; detected by iSystem::GetInstallPath(). ; $/ - The native path separator character; this value is ; supplied by the VFS manager, so you do not need to define ; it here; you can do so, however, if you really want to. ; $CD - The path to CD-ROM. ; $HOME - user's home directory ; A common error is to omit the last $/ from directories. ; This is an error since VFS will treat any path not ending ; in $/ as an archive file name and not as a physical ; directory. VFS.Mount.~ = $(HOME)$/ VFS.Mount.map1 = $.$/patches$/map1$/, $.$/cache$/map1.zip, $(CD)$/data$/map1.zip VFS.Mount.map2 = $.$/patches$/map2$/, $.$/cache$/map2.zip, $(CD)$/data$/map2.zip VFS.Mount.map3 = $.$/patches$/map3$/, $.$/cache$/map3.zip, $(CD)$/data$/map3.zip ; Platform aliases. Aliases are always read first; VFS ; entries specific to each platform override those defined ; in the platform alias section. For example, if your ; current platform is Solaris, VFS will look for the value ; of a variable first in the environment, then in ; VFS.Solaris., and finally in VFS.Unix. (as specified in ; section below). ; Unix-style filesystems VFS.Alias.Unix = VFS.Unix VFS.Alias.MacOS/X = VFS.Unix ; CP/M-style filesystems VFS.Alias.Win32 = VFS.CP/M VFS.Alias.DOS = VFS.CP/M ; Strange key names follow: ; VFS.Unix.. means key '.' in section VFS.Unix.* ; VFS.Unix... means key '..' in section VFS.Unix.* VFS.Unix.. = . VFS.Unix... = .. VFS.Unix.CDROM = /mnt/cdrom VFS.Unix.TMP = /tmp VFS.CP/M.. = . VFS.CP/M... = .. VFS.CP/M.HOME = $(HOMEDIR:$(HOMEPATH:.)) VFS.CP/M.CDROM = x: VFS.CP/M.TMP = $(TEMP:$(TMP:$(SYSTEMROOT)$/temp)) |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |