User:Superleaf1995/lowFS

uniFS stands for Universal FileSystem.

Is a table-filesystem designed by me (Superleaf1995) because why not?

In this filesystem each entry points to a portion of a file, this allows loading parts of the file progressively. If any of the tables is damaged, a checksum every 8 entries is made to ensure nothing is wrong.

This filesystem also tries to be simple as possible, and be compatible with 16-bit hosts as well as 64-bit ones.

Entry

The entry header is basically like a FAT entry, however, this is a header for entries not for files.

struct unifs_entry_header {
    uint8_t reserved;      // Should always be 0xCC
    uint8_t entry_type;    // Type of entry
    uint32_t name_len;     // Length of the name (variable, upon the OS how to handle)
    uint64_t nn_entry;     // Next part of this entry (pointer)
    uint64_t previous;     // Previous entry header in the chain (pointer)
    uint64_t next_entry;   // Next entry header in the chain (pointer)
    uint64_t size;         // Size of entry (unifs_entry struct not included). If set to 0, the host must know the size parsing entry type
};

• nn_entry should be set to 0 if this is the final part of the entry.
• next_entry should be set to 0 if this is the final part of the chain of entries.

Entry types

Following the entry_t header, follows the contents of the entry. Notice that these varies in size, but always should align to 8-bytes.

If entry_type is set to ENTRY_TYPE_FILEMETADATA (0xF0):

struct unifs_entry_filemetadata {
    uint64_t filename_len; // length of filename
    uint64_t len; // length of file in bytes
    uint8_t filename[filename_len]; // variable size, kernel should alloc memory for incoming filename
    uint8_t encrypt; // If it's nonzero, the file is encrypted with some TBD encryption system
};

• Filename should be ended with a NULL character

If entry_type is set to ENTRY_TYPE_FILEPART (0xF2):

struct unifs_entry_filepart {
    uint64_t clen; // Length of the bytes of the file
    uint8_t content[clen]; // variable size, kernel should alloc memory for incoming file content
    uint16_t checksum; // verifies that the data in the file is correct (First byte of content ANDed by the last one)
    uint8_t perm; // use for unix permissions
};

If entry type is set to ENTRY_TYPE_DIRECTORYMETADATA (0xF4):

struct unifs_entry_directorymetadata {
    uint64_t dirname_len; // length of dirname
    uint8_t dirname[dirname_len]; // variable size, kernel should alloc memory for incoming dirname
    uint8_t perm; // use for unix permissions
};

Checksum

The checksum is in total, 8-bytes.

The checksum is a simple 2-byte value 0x53BC. This byte is placed after 8 entries (directorymetadata,filepart,etc). This word should be used for hosts that confides that the disk is OK, in this case, it should skip the following 6-bytes.

In case the host wants to read the 6-byte value, it should AND the aforementioned 2-byte value with the previous 2 bytes before the checksum bytes. Regardless of it being a entry header or a regular entry or not. The result should match the checksum. If a FILEPART entry is before the checksum, the following 4-bytes are the higher 4-bytes of the size of the file. Otherwise it's the 4-checksum bytes.

After the checksum, the entries continue as normal.

A checksum cannot be after the last entry or entry header in a chain.