File System

As in nilnul._data_, Data is defined at different tiers, among which one is a file system, or FS, where data is file and file is data.

Physical Underlining

Driver

As data is boiled down to physical properties, FS starts with a physical driver

If you have a CD driver, you can pop it out, make sure it's emptied of dicks, and you will see the mechanics of the driver: it can swirl a disk that is mounted thence, and it has a sensor which can scan and read the disck.

Inside our computer main casing, there is also a fixed hard disk driver. But unlike a CD driver, the fixed hard disk driver is fixed together with its disk; and the disk cannot be taken out separately with the help from a manufacturer. But when we say driver, it doesnot include the disk.

Disc

We can insert a CD, or compact disc, into a CD driver. The data on the disc then can be read into the computer by the driver. For the hard disc, it's fixed together with the fixed disk driver; only in factory or in the hands of maintainance professionals would we separate the two without damaging them.

Volume

Each pysical disc can be logically formatted into partitions, or further into volumes. On Windows, we have volume C, volume D, etc. Some would refer them as disc C, disc D, etc, but those are inaccurate appellation.

Direcory System

Even with a logically partitioned volume, it's still too large a monolith to manage easily by human per instinct. So we use a strucutre that's slightly more powerful than a simple list to divide it to conquer.

We establish on it a directory system, which is recursively defined:

  1. Each volume has a root directory: "/" (or "\"), which is also called directory separator, or sep for short;
  2. for each direcotry, we can have many dirs; the directory and each dir together form a new direcotry; the containing directory is called base|container|parent, while the contained directory is called child. Note here dir and directory mean related but different things: abc/ is a dir and also a directory, while abc/def/ is a directory, but not dir. In nilnul's ken, we often utilize this kind of nomenclature: a fullword means one thing, and the abbreviation often means a component of that thing.

The folder is then addressed to per the directory system.

File

Each folder can contain a collection of filess.

Location

File and folder are called location. Each location is associated with and referred to by an address.

An address, in contrast with location, can also refer to something that doesnot exist on the disk.

Address

For an address such as c:\abc\def\hij, we can divide it to reduce complexity, thus make it easier to define/learn.

The simplest dividing would be dichnotomy in terms of how many components are divided. We can divide the examplar address as:

  1. c:  \abc\def\hij
  2. or as c:\   abc\def\hij

We use the first way, as we want our definition to be as reusable as we could. With the first, we can keep the reusable part to the maximum,and later, for example in web address, it, but not the c: part, can be reused. With the second, the "\" at the end of "c:\" is not reused, and that is a waste of our effort.

The c: is called vol as we defined earlier; the orther part is called route.

A route is called stem if it ends with "\", otherwise it's called sprig.

If the route is stem, then the address is called Shield; otherwise if the route is sprig, the address is called Spear.

A route without the leading '/' is called division. a stem without leading '/' is called div; a sprig without leading '/' is called document.

Blob

For a file, we not only have the address, we also have its associated content, which we call "Blob"

Blob is backronymed in nilnul as "Binary Linear Object", as it's a finite string of bits. (On the web, blob is interpreted differently as binary large object; we think that's not very correct as some blob is not that large.)

nilnul._fs_._LIB_

This is a C# library to process file system addressings, and some basic blobs. This lib, like any other nilnul libs, is organized as a knowledge base expressed by code; in this way, we make build libraries upon each other to achieve big goals.

It defines many terms to reduce ambiguity as much as possible. So if you want strong and detailed types, of if you have a difficult time to name something as we do, please consider using this library.

It boasts such feature as:

  1. each part and various components are defined as a type; that makes the inspection of addresses easy;
  2. process such as create and read symlinks;
  3. compute relative paths given two addresses;
  4. simple blob processing, including zip files from a dictionary of locations;
  5. some misc but useful toolings, such as exploring a file, or deleting a file into recycle bins, etc.
  6. a configuration system for a folder, elaborated below.

Folder configuration

If you need some meta info for a folder, this library can lend a hand.

Under a folder, we can have some dsts. dst is either a dir or a doc. The name of the dir or doc, without the separator is called dnt. the dnt of such dst is decomposed as:

nub ver exts

The nub is currently always ".nilnul"; the ver is a string of digits, such as 0,1,00,013, 100, or empty string ""; the exts is a string of exts, such as ".abc.def" or empty string.

When we read, only the biggest vers are taken into account. Note prefixing 0s do not change whether a ver is bigger or not.

The exts we usually use is ".xec", where xec means Xml Element Content. We use it to contain the content of an xml element, or as some would say, the fragement of an xml document.

In contrast with empty extension, with an extension, we can open it without being asked what programme to use.

In constract with .xml, the .xec

  1. let us have more freedom; for example we can freely mix text with elements; or we can use custom content, which can be formatted text mixed with custom nested elements, inside an element.
  2. allows multiple child nodes. We can safely append an entry to .xec, and by appending the writing is fast enough for logging; Sometimes we need only the last element, and the reading can also be fast.
  3. can be easily parsed

With the version, we can obsolete some configuration without risking deletion of it. With prefixing 0s as same big ver, we can have multiple entries at the same time for read, while using the one with the most 0s for write.

We can put the configuration in a file such as ".nilnul.xec", or in a folder such as ".nilnul0" as a file. For example, c:\t\.nilnul0\bak.xec would keep configurations about bak(backup); you can deepen the hierarchy till you can simply append (performancewise) entry one by one.

We use such configuration to tag some child folder|file as neglected. We also use such configuration in our solution: nilnul.dev._bak_ to keep record of the bakking time of a folder.