Code: Select all
[INFORMATION BLOCK]
[FILE DATA]
[INFORMATION BLOCK BACKUP]
Code: Select all
[INFORMATION BLOCK]
[FILE DATA]
[INFORMATION BLOCK BACKUP]
- Simple FS implementationjnc100 wrote:What do you need it for?
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:This is not a file system.
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.Kevin wrote:put the file length in the header of the file format and then store it on the raw block device
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.Antti wrote:Why it is not a file system? There can be a file or it can be empty.
Ouch.There can be folders also if the file name contains the path, e.g. "FOLDER1/FOLDER2/ONEFILE.EXT".
In the file header, obviously.Where is the modification time, file name, file size, etc.?
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.It is a security flaw to trust the file header. The file could contain any data.
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".There can be folders also if the file name contains the path, e.g. "FOLDER1/FOLDER2/ONEFILE.EXT
Are you sure? E.g. EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI makes sense.iansjack wrote:The concept of organizing a single file in this way makes no sense.
In this case, the folder path is implicitly defined.iansjack wrote:folders are normally considered to be files
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.Antti wrote:Are you sure? E.g. EFI/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI makes sense.iansjack wrote:The concept of organizing a single file in this way makes no sense.
Then it is not a folder path - it is merely a rather long file name.In this case, the folder path is implicitly defined.iansjack wrote:folders are normally considered to be files
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 filesystemAlso, it could be a "hello world" like file system, e.g. a file system driver template.
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:The EFI directory can contain more than one file
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:iansjack wrote:Then it is not a folder path - it is merely a rather long file name