[openbeos] Re: Filesystems, Namespaces and Data

  • From: Mathew Hounsell <mat.geek@xxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Thu, 8 Nov 2001 01:07:09 -0800 (PST)

In Reply
I reserve the right of reply, for clarification. The main reason I posted
this was to gauge support.=20

'Where is the difference to the current VFS. A file system is only a "data
handler", right here, right now. You can write file system add-ons for ever=
type of data. Adios... Axel.'

Axel has gotten my point, the VFS is Be's implementation of a dataspace. Th=
Virtual File System contains a lot of overhead for dealing with a file
system. I was proposing a simplification of the API to allow data to be
mapped into the dataspace without the concerns of pretending to be a file
system. The VFS api would them map use its subset dataspace API.

'You make the comment "A file system is only a means of mapping an
Identifier=85" Yes, and this identifier is generally tied up with the
semantics of the file system. For example, I probably have any number of
files called "readme". But that simple name alone is not sufficient to
identify the object. So I have to specify '/volume/subdir/foo/readme' and
'/volume/subdir/fee/fum/readme', etc.'

This is not entirely correct. Firstly, "readme" is not the name of the file=
"/volume/subdir/fee/fum/readme" is the name at the current time. This file
name however is not the file's identifier. From the BeBook 'The BEntry only
"loses track" of a renamed entry if the name change is made behind the
object's back.' And '=85the concept of a "node" designates the data parts
(data and attributes) of a file (a file, directory, or link). Contrast this
with an "entry," which designates the entity's location within the file

Most file systems to not use the name to identify the data, an I-Node numbe=
or a FAT entry identifies the file. Access to the file is done by cycling
through the directories and looking up each name in the directory's
namespace until the file's identifier is found.

A file's name is not important to the operation of the file system. The nam=
can be considered just another attribute of the file. Renaming a file would
have significant cost if it were important.

'The neat thing about the BeOS architecture is that it is so modular. =85
Likewise, anyone can write a new server. =85 BeOS makes it easy to build ne=
servers, clients and kits. Then, if we (the community) decided to
incorporate the code, it would already exist, work and would require just a
little back fit.'

I had intended to demonstrate an example of this in action. I sent a messag=
to BeDevTalk asking for advice about implementing servers. I searched
desperately for the information on Be's VFS. I could only find the source
code for DOS FS. Most of the dataspace work should be handled in a server,
Kernel support was necessary for the demands of file systems etc. I will
look at the newsletter for an example of a server. If any one knows of the
documentation on the BeVFS it would be essential.

In a thread a while back, "More misc. ideas" the directory naming in Be was
discussed and this brought up a few of the reasons, I thought, to implement
this. How do we know what to call a directory. Do we care if it's called
"C:\My Incredibly Large Document Folder" or "/export/home/mat/data"? Where
does BeOS place new applications? Does it place a symbolic link to it in th=
folder for the BeMenu? What if I want to write a contact manager? Do I have
to create a new Person file in a directory somewhere, or can I just create =
virtual one? Why do I have to delete an entry in the BeMenu when it is just
a link to another point in the dataspace?

More importantly, how do I store the User Profile? And then how do I cleanl=
re-map the directories used by older programs and the OS, without rewriting
the OS?

I will work on a demonstration to better explain what I mean. Any
information &/ help would be appreciated.

 Get 100% private, FREE email for life from Excite Australia
 Visit http://inbox.excite.com.au/=20

Other related posts: