This is not really a bug as such but its just a suggestion, I also haven't studied this code very long so I could be wrong.
I noticed some of your filesystems extend the disk backed operating system class. I assume this means a filesystem that is on disk?
My suggestion is wouldn't it make more sense to abstract that out entirely rather than extend the disk backed operating system. You may want EXT to be mounted to a file in the future, or a loop back device like Linux does.
Making the filesystem only work on disk is a limitation in my eyes.
Just a suggestion.
As stated I haven't looked at the code very long so I could have misunderstood the way you implemented this
I also noticed you don't have FAT32 yet, if I get some time wouldn't mind giving it a go at implementing it I've implemented FAT32 before and in my old job used to develop filesystem drivers for Linux for a living. Would be pretty interested just want to check this is allowed or if you have enough contributors
Many thanks
@bugaevc suggested the idea of changing the filesystems to be backed with files in the IRC channel sometime ago.
About the FAT32 - It would be very nice if you can work on this, though it's your choice and you're free to work on other things, if you want to :)
Would be pretty interested just want to check this is allowed or if you have enough contributors
There's always room for more :)
Great news, I'll fork your repo shortly and when I find the time I'll implement FAT32, its a fairly simple file system
Many thanks
@nibblebits Please do. I had a FAT32 branch a while ago, but I could never resolve the FAT32->inode stuff (mentally) to get anything working.
Most helpful comment
Great news, I'll fork your repo shortly and when I find the time I'll implement FAT32, its a fairly simple file system
Many thanks