OSDev.org

I plan to create a file system specification. The idea is to have a file system that supports only one file. A scratch layout:
It should be relatively simple to create a FS driver for this. Do you have any suggestions, e.g. features that are important? Data redundancy?

Is it April 1st already? I seem to have missed Christmas.

If there were a well-established specification, there could be use for this. Please note that the file itself could contain another file system. It would be possible to move this file very easily between different systems (after FS drivers for this are implemented).

What do you need it for?

A contributor proposed a patch for one of my projects to implement this. The idea was that any writes to the filesystem would start at byte 0 and be terminated by an EOF mark, thus you could use it for a simple log file and to read it you'd just cat the filesystem. Any fopen to a file on the filesystem would return an identical FILE struct (i.e. one that references the entire filesystem), and if opened in append mode the EOF marker would be searched for and the write pointer set there.

There is a implementation here. The weird thing with 8 tilde marks to mark the end of file was for interfacing with the contributors tools which used this to denote the end of file. It can be disabled.

Regards,
John.

jnc100 wrote:What do you need it for?

- Simple FS implementation
- Security (easy to get rid of driver bugs)

Also, it could be a "hello world" like file system, e.g. a file system driver template.

This is not a file system.

What is the one file that you want to store on it? If there even is a reason for this file to be shorter than the whole device, put the file length in the header of the file format and then store it on the raw block device.

Kevin wrote:This is not a file system.

Why it is not a file system? There can be a file or it can be empty. There can be folders also if the file name contains the path, e.g. "FOLDER1/FOLDER2/ONEFILE.EXT".

Kevin wrote:put the file length in the header of the file format and then store it on the raw block device

Where is the modification time, file name, file size, etc.? It is a security flaw to trust the file header. The file could contain any data.

Antti wrote:Why it is not a file system? There can be a file or it can be empty.

For me, the defining aspect of a file system is that it allows partitioning some storage (typically a block device) into multiple files. I would consider things like metadata as secondary to that.

There can be folders also if the file name contains the path, e.g. "FOLDER1/FOLDER2/ONEFILE.EXT".

Ouch.

Where is the modification time, file name, file size, etc.?

In the file header, obviously.

It is a security flaw to trust the file header. The file could contain any data.

The information block could contain any data, too, if the disk contents comes from a third party. The advantage that you may get by implementing this like a file system is that your metadata is protected if a user can write to the "file system", but not to the block device. So if this is the security aspect you're interested in, fair enough.

The other advantage is that the OS can update metadata instead of doing it in the application.

So if you really have a good use case for this (I don't think I would have one), go ahead and implement it. If you want, even as a file system driver. But it's still not a file system in my book, it's just one piece of storage with a protected metadata header.

There can be folders also if the file name contains the path, e.g. "FOLDER1/FOLDER2/ONEFILE.EXT

Now I know you are joking. The point of folders is to organize files into a hierarchy. The concept of organizing a single file in this way makes no sense. Apart from that, folders are normally considered to be files (albeit special files) so you are not describing a single-file "filesystem".

iansjack wrote:The concept of organizing a single file in this way makes no sense.

Are you sure? E.g. EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI makes sense.

iansjack wrote:folders are normally considered to be files

In this case, the folder path is implicitly defined.

There are already simple filesystems like BFS, SFS or LEAN. To go simpler than this isn't really a file system any more.

If you wanted a single file for reading and writing to try cpio or tar. They are already established file types instead of creating a new one for the same purpose. They also already have tools available so they are easy to work with.

Antti wrote:

iansjack wrote:The concept of organizing a single file in this way makes no sense.

Are you sure? E.g. EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI makes sense.

I'm absolutely sure. The EFI directory can contain more than one file, and more than one directory (on my systems it does), so that is not a single-file filesystem. Of course - as with any file system - you could use it to store just a just a single file. But if you always used it that way you wouldn't need a filesystem.

iansjack wrote:folders are normally considered to be files

In this case, the folder path is implicitly defined.

Then it is not a folder path - it is merely a rather long file name.

Also, it could be a "hello world" like file system, e.g. a file system driver template.

I actually think this is the most legitimate reason to pull this stunt. It forces you to cover all the cases needed in a device driver without actually designing a filesystem

And of course the autodelete forum is the other implied legitimate reason. Still I might do just this if there exists a specification, for the sole reason of this being a nice step-up case.

iansjack wrote:The EFI directory can contain more than one file

That is not relevant. My point was that the path may be important in some cases. The concept of organizing a single file makes sense.

iansjack wrote:Then it is not a folder path - it is merely a rather long file name

That is an implementation detail. Users will be creating a folder and then the file inside it. If I opened my RSFS on Windows, I could do something like this:

Well, have fun with it.

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.