Yeah, I always wondered how the hell all that works... To be quite frank, I really wish that they would make the API simpler... A filesystem structre can't be that complicated (even though M$ somehow managed to completely blow their filesystem's API out of the water and into impracticality).
Let's be realistic: there needs to be some sort of arbitrary API that makes general control of it possible. For example, a data structure of properties, or somthing, and then you can "apply" those properties to: A) a new object (defined by the properties data structure), or B) an existing object.
Then, the other way around would be retrieving the data structure of a file/folder... I honestly don't know why Windows can't do that. I specify Windows, because they seem to make their API so god damn complicated, it's not even worth the time and effort to study (honestly... simple tasks shouldn't be that difficult!).
You didn't actually say anything about how you would structure your filesystem or the API to use it, though, all you did is assert that current APIs are insufficient and then talk about a hypothetical filesystem that allows filenames to contain special characters but has even worse arbitrary limitations than current filesystems.
Also, writing a user space filesystem driver for a made-up filesystem is pretty trivial. You only need kernel access (the more difficult part to code) to write directly to devices.
My only gripe with modern filesystem APIs is the inability to insert into files without rewriting everything. Otherwise, I'm pretty happy with the way things are.
I said "poorly abstracted" and not "poorly designed". But when I aid I was confused, I was definitely confused - I don't know what I was thinking. I've had a bad headache all day. You're right that I'm stupid.
How would you improve filesystem APIs to be better abstracted? Actually, while we're at it, what does "better abstracted" mean? More abstraction, less abstraction, or something entirely different altogether? I mean, it's pretty abstract already: instead of thinking in terms of cylinders, sectors and heads (unless you're writing device drivers) or even blocks (unless you're writing filesystem drivers) we get to think of the filesystem as a rooted tree with branch nodes (directories/folders) and leaf nodes (files). I personally wouldn't want to use blocks, let alone CHS, directly, so I think removing abstraction is out. I also don't see the point in using a different abstraction altogether -- it would most likely just play out in the same way, but with different words (maybe "pages" instead of files and "books" instead of directories). So the option remaining is to add another layer of abstraction -- but what?
Can already tell it's abstracted so much you actually make a distinction between files and directories when there is essentially none in their representation on disk. That's why file systems don't normally allow you to have "files and directories with the same name". The abstraction is fine, it isn't really about conventions or otherwise, it's about readability. If you can't represent a path as a string (you can represent pretty much anything as a string but w/e) you basically make the command line useless and the path not human readable. You are demanding abstraction where there doesn't need to be any.
In any case if you designed an OS as such that didn't follow a convention that basically every other OS does, that would be poor design on your part for you're OS. No one would develop for it and it would simply die off into the abyss.
In any case if you designed an OS as such that didn't follow a convention that basically every other OS does, that would be poor design on your part
This is the only part of your post that I disagree with. Conventions should only be followed when they're conventional because they make sense, rather than being followed because the users are used to them.
I'm with chrisname. I've never liked embedding type information in file names, it's also seemed like a hack to me. I'm always annoyed that so many limitations from years ago when those limitations were practical are still carried over into modern technology where the limitations make no sense.