Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
iansjack wrote:
I still don't think it's a filesystem and not even useful as a template for one. It fails to address some of the most basic points of filesystems such as allocation of storage space. It's not so much a
printf("Hello World")
filesystem as a
puts(’H')
one.
Agreed...
@Antti It's just a file with an internal structure without much to gain over a regular flat file. The same thing as your mkdir/cd/type example could be done using existing file types like tar or zip. Working with a stored zip file (compression method = 0) would handle all the same tests you want to do without having to write the tool to create the file. The format really isn't complicated, check out 4.3.7 for the file meta data. If you really want a system simpler than this you can just ignore everything but the uncompressed size and the filename.
Combuster wrote:It forces you to cover all the cases needed in a device driver without actually designing a filesystem
Yes and it is easy to have a device driver that is really perfect, e.g. no missing features. It is simple but it works. Perhaps in the future all hobby OSes have an "rsfs.c" in their "fsdrivers".
b.zaar wrote:Working with a stored zip file...
An interesting side note, I studied that format few months ago. I thought I could use it as a boot RAM disk but I discarded that idea for now. But yes, the zip format could work.
Please note that an RSFS partition must be bootable. Perhaps the structure could be something like this:
b.zaar wrote:So it's just a wrapper around real files?
I would not want think it that way. It is a full file system on its own. How the file data is handled, e.g. if it is a file system image, is not RSFS's policy.
Flag Description
0x0001 reading allowed
0x0002 writing allowed
0x0004 executing allowed
0x0008 deleting allowed
0x0010 archive flag
Other flags are not used and they shall be zero.
Volume offset and size
Volume offset defines how many bytes there are before this volume in a storage device. The size defines the RSFS file system size in bytes.
File offset and size
File offset defines how many bytes there are before the file data (starting from the beginning of RSFS). Must be at least 512 bytes. File size defines the file data length in bytes.
Creation and modification time
The number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, not counting leap seconds.
File name
E.g. "FILE.TXT", "FOLDER/FILE.TXT". Name rules defined later.
This is an informal description but you got the idea. I need to write an extremely official specification. Otherwise this is pointless and no one is going to use it.
And instead of bothering with the notion of leap seconds, you may want to consider using TAI or GPS seconds instead, and add a conversion to UTC/POSIX time as an implementation note.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
But a filesystem is more than a means of storing a single file. The essence of a filesystem is that it divides the data stored on a device into named chunks, which conventionally are known as files. Most useful filesystems also organize those files into a hierarchy of containers known as directories.
A "filesystem" consisting of a single file is similar to a Periodic Table containing only one element - and just as useful.
I could see the advantage in writing a gzip file directly onto to a block device.
But then why don't you just write it directly to the device, without a pseudo-filesystem in between? Do you really need any filesystem metadata? (Well, for gzip it actually looks like you need to have the file length, but for a database I'd expect this information to be contained in the file data.)
