The filesystem is a database, but it has always been unsuitable as the computer’s primary one. Programmers have to write specialized programs to get
the functionality they need. Now, new advances in software like Plan 9, the Reiser 4 filesystem and Linux are making the improvements the filesystem needs to
become viable. Plan 9 is using the filesystem as the integral system interface, and the Reiser filesystem is unifying pointlessly different but equivalent namespaces. For operating systems to improve for users (that always includes programmers), they need to incorporate these new ideas.
New Advances in the Filesystem Space, PDF File
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I read this and then printed it out. Excellent research, very very cool. I can’t wait to manages mp3s…
$cat /home/adam/music/A\ Day\ In\ the\ Life.ogg/artist
The Beatles
(or something like that…)
hmm…
charg -r –artist=”The Beatles” /home/panzi/mp3 and ogg/beatles
THAT would be nice!
Panzi, with the system the author proposes, that would be a mere shellscript. Instead of a C app which brings it’s problems (maintainance) with it.
All in all I think it’s a nice idea. The stacked mounting is a bit overdoing it I think. It might be overly complex or I just might not grasp it well enough.
I never thought that Unix can be made more simplier than it already is. The main idea of Unix is that combining of simple tools will create powerful solutions. Now the tools can become even more simplier, so there is enough room for creative combinations of them. If these ideas become mainstream, this will cause a revolution in OS-design. Finally I can get rid of set, setenv and similar ugly things, which I never really understood. Can anyone tell me the difference between set and setenv on AIX?
Anton
…Used to host all of the articles as files in the BFS, and query with attributes. I always thought that was pretty cool, and wondered why more people didn’t do that. Actually, more to the point, I wonder why it’s taken so long for even companies even like micro$oft to realize the value in something of that nature. Hint, hint longhorn with the upcoming database like filesystem. Somehow I don’t see them getting it to work anywhere as nicely as BFS did though. I saw a quote something about apples new iChat software, to the effect that while microsoft focuses on new features, apple focused on simplicity and elegance. Couldn’t be any truer.
My 2cents.
> Finally I can get rid of set, setenv and similar ugly
> things, which I never really understood.
Using the filesystem to store environment variables is the standard on AmigaOS since it was born… also, many of the things explained in that paper are either already available (see Plan9), or thought by someone else already. Not trying to discredit the paper’s author, just stating that all that is not really “new”
I don’t like renaming a file foo.ogg in a file foo with an attribute type=ogg inside, it hides the type of the file.
What happens if I dowload a file foo.ogg with an attribute type=exe inside? Lots of trouble!
I think that the filename is a ‘communication handle’ with the user, and the type of file is important enough to be part of the filename not hidden inside an attribute..
If you are to have these attribute minifiles store data for folders too, you chould run into problems.
For example:
/folder/uid
/folder/gid
Means you can’t have files named uid or gid in folders (I guess that’s why they have double-dot prefixes in the document. But dotfiles seem a little hacky to me…)
I like the idea of a unified namespace, but not the way the UNIX approaches it. Personally I think it would be better to have ‘volumes’ (which could be single or multiple partitions tied together as a single logical volume) in a ‘fs’ subdivision of the system namespace, which would have ‘dev’, ‘info’, ‘config’, etc. subdivisions. Or maybe I’m archaic in thinking that different system resources should be differentiated depending on the physical realities? Dunno. Interesting stuff though.
I don’t like renaming a file foo.ogg in a file foo with an attribute type=ogg inside, it hides the type of the file.
What happens if I dowload a file foo.ogg with an attribute type=exe inside? Lots of trouble!
I think that the filename is a ‘communication handle’ with the user, and the type of file is important enough to be part of the filename not hidden inside an attribute..
I couldn’t disagree more. Why should the user care what type a file is anyway? Surely only programmers care about the specifics of data encoding formats. The user only wants to know it’s a music file, which you can show in an icon. Or with a program like LS, it could read the type file and display it on the screen next to the file name.
Seriously, I met this guy once who though you could change the format of a file by renaming the extension. Duh. I couldn’t believe my ears. In fact that influenced me a lot in believing the file extensions are an evil hack (well that and those Ars Technica articles
.
Anyway, If you download foo.ogg it won’t have all those extra info files, unless the transfer protocol supports them. It’s the job of MIME types to tell the client the type of a file. It wouldn’t be much work to translate the MIME header into the FS-specific type name and create a type file for the file once you’ve finished downloading it.
What happens if I dowload a file foo.ogg with an attribute type=exe inside? Lots of trouble!
This is just a question of sane user interface design. In fact, most browsers should have fixed this by now, considering that HTTP servers can send mimetypes anyway.
The solution *drumroll*: Alert the user whenever an external application is about to be launched, and give them enough information to decide what to do. E.g. “Do you want to open foo.ogg in ABCPlayer or save it to disk?” as opposed to: “Warning: foo.ogg is an executable that could potentially harm your system. Do you want to execute it or save it do disk?”
Of course, this isn’t a real solution either. The real solution would be to implement a proper operating system design that inherently protects the user against malicious programs.
Is is quite unreasonable for _any_ program to have access to _all_ the files that the user has access to. A text editor, for example, need only have access to the files/directories containing its configuration, and to the file that is currently being edited.
Of course, telling the operating system which parts the text editor should be able to access is not that trivial.
There have to be user-defined permissions per executable or type of executable, to tell the operating system what files said executable can always access. These permissions can obviously be backed by system-wide defaults.
Now all the text editor still needs is permission to access to the file that the user wants to access. This permission should be given by the Load/Save File dialogs when the user selects a filename. Obviously, the Load/Save dialogs need to run in a different process space (probably that of a user-trusted daemon).
It gets more difficult (a _lot_ more difficult) when programs such as IDEs are involved. Obviously, the “Load Project” dialog can give the IDE process permission to open the project file, but what about permission to access the files that are associated with the project?
We face a similar problem with CLI programs – we’d basically have to either trust the CLI program to manage permissions itself (which is a big no-no for programs downloaded from the internet), or the shell has to invoke some kind of subscript to parse the program parameters in order to figure out which files the program is allowed to access.
> /folder/uid
> /folder/gid
> Means you can’t have files named uid or gid in folders (I
> guess that’s why they have double-dot prefixes in the
> document. But dotfiles seem a little hacky to me…)
Indeed, that’s a problem of the proposed implementation… for AROS I’m designing a component system based upon many of those ideas, it’s called CABOOM. In CABOOM files are objects, everything is an object, and objects can have attributes. Every object is potentially a “context” (term taken from Nemesis – http://nemesis.sf.net/), and you access contextes by means of the ‘/’ character. Every context can contain 0 or more objects, and since contextes are objects themselves, they can contain other contextes, leading to the well known hierachy scheme.
Now, objects’ attributes live in a different namespace than the objects contained in the object itself, you access them by means of ” (backslash), rather than ‘/’, so there’s no way that conflicts can arise.
Hi folks,
How does all of this stuff compare to Oracle’s OFS?
Yours truly,
Jeffrey Boulier
I heard of a filesystem for an operating system students at Oporto’s State University for Engeneering are developing for the OS they’re also developing. It’s called JDynFS. I saw a screenshot of a test once, where they did something like
attrshow -rt[no-open,basic,type] file.movie
and it returned somthing like
<size>15666055</size>
<filename>file.movie</filename>
<title>Test stream</title>
<encoding>DivX-codec-type-nnn</encoding>
<author/>
but the data wasn’t beeing read from the file. instead it was stored on the file’s inode. apparently, the OS recognizes only one format per file type, and the FS works as if it was a big database. you can actually use some FS instructions that use xml data directly. for example, any jpeg, gif, png that you copy to the fs is automatically converted to their format (I believe they use png), and get a name like filename.img or only filename. the inode indicates the type of document.
Plan 9, quite simply, rules the school
You can do stuff like union folders (ie binding the contents of two folders together), and you have absolute network transparencies, so if you want to run someone else’s binaries, you bind their binary directories say at /n/somefolder/bin to your binary /bin and programs will be none the wiser…
You could even do that with devices as well…
Makes me wish this kinda stuff was in other OSes as well..
>Using the filesystem to store environment variables is the >standard on AmigaOS since it was born… also, many of the >things explained in that paper are either already available >(see Plan9), or thought by
Also comments on files were/are possible on AmigaOS
and it could be used for mp3 artist too….. But what i like the most i url of downloaded file in file comment.. that is SO usefull….
By renoX (IP: —.w80-14.abo.wanadoo.fr) – Posted on 2003-07-15 21:21:30
I don’t like renaming a file foo.ogg in a file foo with an attribute type=ogg inside, it hides the type of the file.
What happens if I dowload a file foo.ogg with an attribute type=exe inside? Lots of trouble!
I think that the filename is a ‘communication handle’ with the user, and the type of file is important enough to be part of the filename not hidden inside an attribute..
————————
If it is standardized so that all files have a type/ directory, then the ls command could simply be modified to display the type attribute. Same goes for any application such as email clients.
When I talk to people who don’t know a lot more about computers than what they read in PC Magazine, I ask them what big changes are in store in Longhorn (because PC Magazine devotes about one paragraph an issue to non-Windows platforms), and their eyes light up as they say, “the file system is going to be DATABASE driven!” I say, “Oh wow, that’s different,” and they go, “yeah!”
Who cares about linux file systems. I can’t wait for this latest innovation from Microsoft.
Melivula you are a TROLL.
Microsoft does NOT innovate, they stole. Period.
Eugenia: I HATE this shity board. Could please do some work here? Slashcode hmm?
Oh no, no Slashcode please! I hate the layout of Slashdot. It’s so messy and you gotta have an account or else your treated like dirt. And then people’s comments are just burried under “better” ones. Leave the board the way it is…
Interesting enough, if hardly new.
To be honest, I miss devices in modern OSs, they gave AmigaOS much of its power. Guess you can do the same in POSIX, but somehow treating everything as a file or directory in a single rooted hierarchy doesn’t feel right to me, TCP: over /dev/tcp for example.
And logical devices, particularly multi-homed ones were massivly useful. I never bothered with adding directories to the path, I just added directories to C: and they were in the default path anyway. Being able to organise fonts into multiple directories and still have the OS able to find them all via FONTS:, and being able to boot from a floppy, mount a HD (home brewed interface…) and then make the HD the boot device (re-assign SYS: etc)…
But all that’s probably just me…
OS/400, the operating system of IBM’s AS/400 midrange line, has been treating everything as database objects since the 80s…. everything, meaning devices, user profiles, etc.
This idea with the dot files, isn’t that a bit like the Resource Fork we know from the Apple? If you would implement that, it would solve the problem too, without losing the ability to create a ..mounts file, for example. And still only one tool, something like “chres”, should be programmed in C [++/#]. Maybe it might then be used as something like this:
$ chres –tofile=/tmp/$$$.xxx –res=”mounts” mydir
$ vi /tmp/$$$.xxx
$ chres –fromfile=/tmp/$$$.xxx mydir && rm /tmp/$$$.xxx
The replacement for /etc/passwd (half-replacement, I know) would still need to be implemented as suggested in the article, but that should be no problem.
Someone asked about set and setenv, so I’ll answer:
in csh:
set sets a variable for the current shell, and setenv sets a variable for the environment. The difference is if I start another shell or program from the current shell, it will be able to see the setenv var, but not anything I set using set.