Anonymous filesystem

An anonymous filesystem is a filesystem that is not bound to a domain. Even anonymous filesystems have a domain that can be used to print the absolute path of its files, but you can't use that domain from outside the anonymous filesystem to access it.

It is a temporary filesystem that only exists for the duration of a transaction.

An alternative way of thinking is that an anonymous filesystem is not mounted anywhere. As soon as you mount it to a non-anonymous filesystem, it will stop being both anonymous and temporary.

Attribute type

File attributes are strongly typed. For example, they may be of type string or int32.


Files contain buckets which may contain other files. You can ignore buckets and access the all the children files of the parent directly, or you can access all the children within a single bucket.

Buckets are defined by apps. Each instance of the app automatically contains all defined buckets. You may also place a file into a bucket without defining it first. In this case the bucket will be used but not defined - it will be an undefined bucket.

Apps may define what methods a file needs to implement in order to be placed into a bucket. Such rules can be circumvented for now.

Compressed size

In the context of Boomla filesystems, compressed size is a synonym for deduplicated size.


A file is said to be a content if it implements the .Inline interface.

Data deduplication

If you have multiple copies of the same file, Boomla will figure this out and only store it once physically with multiple references. This is called data deduplication as the process "removes duplicates" from storage.

If we make 1000 copies of a 10MB image, we still end up with a deduplicated size of just over 10MB.

Deduplicated size

Deduplicated size is the storage space required for storing a file and its entire subtree on disk, with data deduplication applied. Data deduplication is automatically applied by Boomla.

The deduplicated size has to be individually calculated for files, thus you can't just look it up, it is an expensive operation.

Dynamic Filesystem

Each website (branch) contains a Static Filesystem and a Dynamic Filesystem. The Dynamic filesystem is used to store unsupervised data, for example collaborative data and logs. Data on the Dynamic Filesystem is typically created in the production environment.

It contains linear, sequential changes.


A file is an object for storing data, similar to the traditional concept of a file, with some differences:
  • Boomla files may contain other files; there is no separate concept for directories.
  • Boomla files are ordered and you can sort them.
  • Boomla files can store structured data, so you can use the Boomla Filesystem as a database.
  • Boomla files are typed; they have a dedicated type property instead of using file extensions.
  • Boomla files have a link property which lets you create various kinds of file links.

File attribute

File attributes are (key, value) pairs defined in user space. File attributes are strongly typed. One can store data in file attributes which would traditionally be stored in database rows.

File link

A file link is a pointer to another file.

Key points:
  • There are several types of file links.
  • Depending on the link type, the link may or may not be automatically followed during a file operation.
  • Some file link types are used to mount sub-volumes.
  • The link property is ALWAYS accessed on the LINKING file.
  • A link is defined by its type and any number of type-specific parameters.
  • File links are either hash-based or location-based.
  • path /gallery/smile.jpg
  • package 01ed8bb7a8ad5500c8885da1575f77068d0777606d
  • volume
  • scope
  • dynamic

File property

File properties are system defined (key, value) pairs storing file metadata. Examples include the file link, type, title, status code, creation and modification times, etc.

File type

The file type is a file property, holding a built-in type or an internal path to a file. Relative paths not starting with . or .. are resolved relative to the /sys/packages file. For example, the type would resolve to /sys/packages/


A fileId is a unique identifier for a file within a filesystem. When a file is moved within the same volume, its fileId won't change.


A fileNodeId is a unique identifier for a file within a volume. When a file is moved within the same volume, its fileNodeId won't change.


A filesystem is a tree of one or more volumes.

Filesystem interface version

The filesystem interface version defines the filesystem schema and any additional behavior on how the Boomla OS shall treat the filesystem / website in context.

Each filesystem scope defines its own filesystem interface version.

Filesystem scope

The filesystem scope specifies the root file to be used for path resolution. Filesystem scopes are implicitly created by some of the file link types. Filesystem scopes always start at volume roots. A filesystem scope may be local or global.

Filesystem scopes are used within packages to resolve file links and file types correctly.

Hash-based link

A hash-based link mounts another volume by its hash. The mounted volume is part of the filesystem and the link can not break.
Modifying a volume mounted via a hash-based link causes hash change propagation in the linking volume.

File links are either hash-based or location-based.


The IDE is an Integrated Development Environment which can be installed on any Boomla website as a package. It provides a filesystem navigation tool and an editor for code, file properties and file attributes.

Ignore filesystem scope

Some filesystem operations may ignore the filesystem scope.

For example a package link that mounts a package filesystem establishes a new filesystem scope. Consequently, within the package, the root file refers to the package root. When ignoring the filesystem scope, the root file refers to the root of the outer filesystem.

Also, the parent file (..) of a package root file does not exist when respecting the filesystem scope. It does exist when the filesystem scope is ignored.


Immutable means not mutable, or unchangeable. For example, Boomla filesystem snapshots (versions) are immutable. Whenever you "make a change" to a filesystem, in reality, a new filesystem is created - the previous snapshot (version) remains unchanged.

Integrity check

Integrity checking a filesystem is the act of validating all of its data structures. If the integrity check passes, all data is accessible and intact, no single bit has been damaged.

Link type

A file's link type defines how Boomla treats the link during file operations.

Available link types and their main properties:
Link type Address type Transparent Filesystem scope Mounts volume
package hash-based yes yes yes, read-only
scope hash-based yes yes yes, read/write
volume hash-based yes no yes, read/write
dynamic location-based yes no yes, read/write
path location-based no no no

Location-based link

A location-based link is a reference to another file by its path or other means. The link may be broken as the referenced file may or may not exist.

File links are either hash-based or location-based.


Mounting means linking another volume from a file so that the linked volume becomes accessible as the linking file's subtree.


A file is said to be a page if it implements the .Page interface.


A placeholder is a drop zone on the user interface that is routing dropped files to a specific bucket on the filesystem.

Placement direction

When creating, copying or moving files, one has to instruct Boomla how to position the file relative to an existing file. The placement direction is one of prepend, append, before or after.

Posix bridge

The Posix bridge is a 2-way mapping between the Boomla filesystem and Posix filesystems. Posix filesystems in this context include Windows, Mac and Linux filesystems.

The Posix bridge allows one to use programs that understand Posix filesystems to manipulate Boomla files.

Property file

A property file is a JSON file on the Posix side of the Posix bridge, suffixed with ~.json. It stores file properties and attributes.

Reserved filenames

Reserved filenames are system filenames white-listed for specific uses. For example, the filename .Request is reserved for request method files.

Root file

A root file is the top-most file of a volume or filesystem.

Root filesystem

The root filesystem is the top level filesystem of a branch (website).

Root volume

A root volume is the top-most volume of a filesystem.

Static Filesystem

Each website (branch) contains a Static Filesystem and a Dynamic Filesystem. The Static filesystem is used to store supervised data, for example the website's codebase, pages and blog posts. Data on the Static Filesystem is often version controlled and requires non-linear development (branching, merging). It is a trusted storage area that is read-only in the production environment.


A subtree is a file with all its descendants, crossing volume boundaries.

System filenames

System filenames are filenames starting with a dot followed by an uppercase letter, for example .Request. System filenames can only be used if they are among the reserved filenames.

Transparent link

A link is said to be a transparent link if it lets you transparently read and write the linked file's data except the following:
  • name,
  • file hash,
  • subtree size,
  • fileId,
  • fileNodeId,
  • link.
The rest of the file's data is accessed on the LINKED file:
  • type,
  • title,
  • status code,
  • attributes,
  • body,
  • children,
  • created, createdBy,
  • modified, modifiedBy,
  • subtreeModified, subtreeModifiedBy.
For example, a volume link is a transparent link, while a path link is not.

Type chain

The type chain of a file is the collection of files you encounter by recursively following a file's type property. All type chains must end in a built-in type. The type chain of a file includes the file itself.


A volume is a tree of files. Two files are on the same volume if you can reach one from the other without following file links. Volumes may be nested via file links.