The goal of this work is to create a limited but fully functional user system file system. The system called cfs (container file-system) provides all of its entities (files, directories, and links) as well as all of its functions within
a regular Linux file. Cfs-hosting files have the suffix ‘.cfs’ to are separated from normal Linux files.
Cfs essentially provides the tree-like structure of Linux FS over its core components which are files, directories and links. Also, a number of functions need to be implemented in cfs and these include creating, deleting, displaying and modifying files, directories and links. The full description of the commands is given below. These commands must be executable
from the shell (i.e. ordinary command line). Physically, all the files of a cfs are stored in a single regular Linux file which is placed in a specified position on the disk, e.g. /home/users/myfile.cfs. Beyond the basics
operations, it supports the functionality of importing and exporting files and directories from
cfs on the Linux file system and vice versa.
Most important functions of this File System are:
cfs_workwith <FILE>
The following commands will be executed in the cfs file given in the parameter .
cfs_mkdir <DIRECTORIES>
Create a new directory with the name (s) .
cfs_touch <OPTIONS> <FILES>
Create file (s) or if the listed files are modified file seals . In case of modification of the time stamps the are:
a: Renew access time only.
m: Refresh modification timeline only.
cfs_pwd
Show current directory starting at the top of cfs.
cfs_cd <PATH>
Change current directory in . The option also includes the current one directory ‘.’ or the parent directory ‘..’
cfs_ls <OPTIONS> <FILES>
Print file contents where are:
a: View all files including hidden (files named starts with the character ΄.΄)
r: Retrospectively print files based on the current directory
l: View all file attributes. The features that you should definitely have included are creation time, last access time, last modification time and size.
u: View files without sorting, but in the order they are stored in the directory.
d: View only directories.
h: View links only.
and are: one or more entities located at that point in the cfs hierarchy.
cfs_cp <OPTIONS> <SOURCE> <DESTINATION> | <OPTIONS> <SOURCES> ... <DIRECTORY>
Copy files and directories from to or copy them (possibly many) in .
The flag options are:
-R: Copy the contents of the directory to a depth of -1 in the .
-i: Copy after user acceptance, after system query.
-r: Retrospective directory copying.
cfs_cat <SOURCE FILES> -o <OUTPUT FILE>
Merge the into the . The list is meant as a list normal files. is a regular file (re-) created with mandate.
9.cfs_ln <SOURCE FILE> <OUTPUT FILE>
Create a new file that is a hard link to the file. Links of this format to directories are not allowed.
cfs_mv <OPTIONS> <SOURCE> <DESTINATION> | <OPTIONS> <SOURCES> ... <DIRECTORY>
Rename to or move the (probably many) to .
The flag options are
-i: Move upon user acceptance, after system query.
cfs_rm <OPTIONS> <DESTINATIONS>
Delete files in the directory (s) in-depth-1 without delete contents lists that may exist in . The flag options are
-i: Delete file system components after system query and acceptance of the user.
-r: Retrospectively delete all directories that contain and include directories described in .
cfs_import <SOURCES> ... <DIRECTORY>
Import files / directories of the Linux file system into its cfs.
cfs_export <SOURCES> ... <DIRECTORY>
Export cfs files / directories to file system Linux.
cfs_create <OPTIONS> <FILE>
Create a cfs in the file.
Possible flag options are:
-bs : Specify data blocks in Bytes.
-fns : Specify filename size in Bytes.
-cfs : Specify the maximum file size in Bytes.
-mdfn : Specify maximum number of files per directory
Implemantation techniques
Physically all cfs components are placed under a single .cfs file.
As is the case with most file systems, so in cfs, for every entity there is
corresponding metadata entry. In ext2 / ext3 / ext4 this structure is called inode-structure.
In cfs the structure must include a file / directory / link name, attribute
file number that corresponds to the inode-number and can be used to index
cfs entities, size, type, creation time, last accessed and last modified, parent directory (if any) and a list of data blocks.
An example of a metadata structure is as follows:
typedef struct {
unsigned int nodeid ;
char * filename ;
unsigned int size ;
unsigned int type ;
unsigned int parent - nodeid ;
time_t creation_time ;
time_t access_time ;
time_t modification_time ;
Datastream data ;
} MDS ;
typedef struct {
unsigned int datablocks [ DATABLOCK_NUM ];
} Datastream ;
The nodeid field is the characteristic file number that is unique to cfs, the size is the size of the file and type is the type of file. The basic types include: simple file, directory, link. If the cfs filesystem entity is a directory, then the parent-nodeid field symbolizes the parent directory attribute number. The fields creation_time, access_time and modification_time is the time of creation, last access and last modification, respectively. Finally, the data field holds the number of blocks occupied by that entity. In the above structure, the simplest form in terms of data is shown which is a table of numbers block, maximum number DATABLOCK_NUM. This does not mean that everything should be used block.
Data storage technique:
More specifically:
We save a block (superblock) with information at the beginning of the .cfs file, useful for the operation of the file system.
Executing cfs_create creates a file system with .bin and root folders.
Each element consists of one or more blocks, where in the first block we save a struct metadata which contains useful information for each element(directory,file,link).
Directories consist of one or more blocks, where in the first block there is initially a struct metadata stored and then followed by other structs that are "markers" in its contents.
The size of directories is dynamic, specifically whenever one block ends in size, another and its characteristic are bound number is stored in the metadata table. That way no we commit block from the beginning but dynamically and depending on the demand.
The size of the files is the size of the array in the metadata on it the size of a block.
