User:Superleaf1995/lowFS: Difference between revisions
no edit summary
No edit summary |
No edit summary |
||
Line 1:
uniFS stands for '''Universal FileSystem'''.
Is a table-filesystem designed by me (Superleaf1995) because why not?
== Spec ==▼
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.
<source lang="c">
struct
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
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
};
</source>
Line 29 ⟶ 33:
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
};
</source>
Line 51 ⟶ 56:
};
</source>
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.
| |||