I'm rebelling against poorly abstracted file system APIs

[LB]

http://www.LB-Stuff.com/rebel.html

OK, I'm done rebelling now. If you're in a bad mood after that, this will cheer you up:

http://www.LB-Stuff.com/spline.html

[ne555]

I laughed at the 1lI| part

> http://www.LB-Stuff.com/spline.html
¿? the control points are not the same

[IWishIKnew]

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!).

Anyway... I'm just ranting now...

[LB]

ne555 wrote:

¿? the control points are not the same

What do you mean? I only cropped the images from the Wikipedia article. The top image is the second derivative of the bottom image.

@IWishIKnew: I was more rebelling against the poor abstraction in general and less against the complicated API of any one OS.

[chrisname]

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.

[LB]

How did API come into this at all? What ever gave you the impression I was talking about the API? I'm so confused...

[chrisname]

Read the title of the thread, smart guy.

LB wrote:

I'm rebelling against poorly abstracted file system APIs

[LB]

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.

[chrisname]

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?

[Vlad Licker]

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.

[S G H]

I think this may have got to do with why brainfuck was invented.

[chrisname]

itz rex wrote:

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.

[LB]

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.