The good news is that it is not required for you to know or remember the internal structure of a Metakit database used with mk4vfs, because from the script level, you operate on its contents in a normal way, as you would on other file structures. If you feel that you do not need to know more about it, you can go directly to the next section.

Why was Metakit chosen as the practical implementation of the VFS container? It is the nested subviews feature that makes it a perfect candidate to reflect directories and files, as you will see in the next example.

So what really happens when you write a file into a directory that is mapped to a Metakit database? An appropriate VFS driver, in this case mk4vfs, captures the request to save files and stores them transparently in the database. Based on the knowledge that you already gained from this chapter, you can easily have a look into this database to get some idea of how the files are stored. The following simple code is one of the possibilities:

package require Mk4tcl
mk::file open myKit C:\myKit.mk
puts nonewline "layout of myKit: "
puts [mk::view layout myKit]
puts -nonewline "size of myKit.dirs: "
puts [mk::view size myKit.dirs]
puts "contents of first dirs entry:"
puts [mk::get myKit.dirs!0]
puts "contents of first files entry:"
puts [mk::get myKit.dirs!0.files!0]
mk::file close myKit

The code produces the following output:

layout of myKit: {dirs {name parent:I {files {name size:I date:I contents:B}}}}
size of myKit.dirs: 1
contents of first dirs entry:
name <root> parent -1
contents of first files entry:
name README.txt size 12 date 1256126970 contents {hello World!}

What the code does may be described as a reverse-engineering of mk4vfs operations. Instead of going through the specification, we inspect the database directly to understand its layout. First we load the package Mk4tcl and open the myKit.mk database. Next we would like to learn what the layout of the database is, so mk::view layout myKit comes handy. Let's analyze its output carefully:

{dirs {name parent:I {files {name size:I date:I contents:B}}}}

We see that myKit.mk contains one view called dirs. This view (table) consists of the columns with name (by default, it is simply a string), parent (integer value), and the nested subview named files. The names are self explanatory. The dirs view represents the entire directory structure inside this virtual folder. name is the directory name and parent points to a directory at a higher level (the number in the dirs row represents that directory).

Each directory has a subview called files where all the files belonging to this directory are stored. Each row in this subview consists of:

Next, the entire number of rows is printed out using mk::view size myKit.dirs command—in this case, there is only one entry corresponding to the top-level root directory. mk::get myKit.dirs!0 is used for getting the first directory entry:

name <root> parent -1

mk::get myKit.dirs!0.files!0 returns the entry for the only file in this directory:

name README.txt size 12 date 1256126970 contents {hello World!}

The filename is README.txt, its size is 12 bytes, and its content is the text 'hello World!'.