[openbeos] Re: FS attributes
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 7 Jan 2002 01:50:52 +0100 (MET)
> > started on Windows...). How hard is it to make the reported
> > file size include the size of all attributes?
> Not too hard. The trouble is that some older software will break
> when the file size doesn't match the amount of data it reads. But
But it doesn't make any sense. For most data it's completely
understandable to have one main data chunk, while all other attached
data is meta-data.
So it would always be nice to have the size of that particular stream
showing in the GUI and everywhere.
Of course this wouldn't be the case if you would use the other
"streams" or "forks" for standard data - in this case you would end up
replacing file formats with an on-disk hierarchy.
If BeOS would be the only OS on earth, one could think of this as a
good idea.
> it could be done relatively easily in OpenTracker so that the GUI
> display of the file size includes attributes (but it would have to
> scan the attribute list for each file to add up the attribute sizes,
> which will make it slightly slower).
It would be much slower - it would be far easier to let the FS manage
the total attribute size, which could be easily done and would be much
faster.
> Oddly enough I was discussing this sort of thing in the ReiserFS this
> weekend. With objects instead of files, the attribute for the former
> data would only be there (perhaps given an attribute name like
> "default-data") for backwards compatability for software which
> opens the file/object using the old APIs (essentially not specifying
> the attribute name). For that matter, attributes are essentially
> files,
Yes, it's pretty much an API restricting thing.
> they have a size and a name, plus they have a primitive attribute
> data type (int-32, double, string, etc). Objects (the new "file")
> would be like a mini-directory containing attributes. We also
> thought
> of having sub-objects (subdirectories), a unique ObjectID and an
In fact, in BFS attributes are in an attribute directory of a file -
it's a similar approach with the focus on *the* main data stream, which
is perfectly okay.
Although subdirectories are theoretically possible using this design,
it's not used at all.
You could compare what you want with what MacOS X does - it displays
the user a file which is in fact a directory making a RTF with pictures
or whatever.
Unfortunately, this metaphore didn't make it to the shell; you have to
*know* what is a directory and what is a directory that should look
like a file.
OTOH having an extra file for every attribute is too slow for certain
things (like embedded icons), so BFS uses extra space in the inode to
store attribute data.
So even if it's a theoreticaly good idea, it's too slow for real life
usage in some things (of course you could create an index for stuff
like this).
> doing file system traversals and so on. We also came up with a
> better
> way of doing query evaluation - make the indices appear as
> directories
> and have change notification drive the query engine, which would now
> be in a user level library (so that you could use different query
> languages if you wished, and that file system writers don't have to
> make their own query engine).
Although indices *are* directories in BFS (the index itself uses the
same algorithm as a simple directory), it's hidden from userland.
There is no API to access them this way, which is bad.
But OTOH you can't force a file system to use a particular index
implementation so there has to be a layer to access it - I haven't
thought too much about it, but I think the simplest way to accomplish
this is to have the query engine attached to the file system (or as an
add-on in userland).
But of course it would have been nice if this engine would get a
preparsed query tree, not a flat string which it has to parse first.
Adios...
Axel.
Other related posts:
