Return to BSD News archive
Newsgroups: comp.os.linux.development.system,comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!newshost.telstra.net!atlas.onthe.net.au!vic.news.telstra.net!news.mira.net.au!harbinger.cc.monash.edu.au!hobyah.cc.uq.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.ysu.edu!usenet.ins.cwru.edu!agate!howland.reston.ans.net!gatech!newsfeed.internetmci.com!csn!news-1.csn.net!uucp-1.csn.net!auto-trol!chrhas
From: chrhas@auto-trol.com (Christopher Hassell)
Subject: A ResFork solution? Apply DB ideas (was Re: Ideal filesystem)
Message-ID: <chrhas.828135456@auto-trol>
Organization: Auto-trol Technology
References: <4hptj4$cf4@cville-srv.wam.umd.edu> <3140C968.20699696@netcom.com> <4ilgto$861@floyd.sw.oz.au> <4j6if4$15gk@news.missouri.edu> <315834CD.7C4DA6C7@netcom.com>
Date: Fri, 29 Mar 1996 21:37:36 GMT
Lines: 236
Xref: euryale.cc.adfa.oz.au comp.os.linux.development.system:20300 comp.unix.bsd.freebsd.misc:16298
Adam Megacz <kalessin@netcom.com> writes:
[ It seems that the discussion of EA's in this group has been going in three
[ directions:
..<deleted to use below>..
[ --
[ Adam Megacz <kalessin@netcom.com>
[ Website ftp://ftp.netcom.com/pub/ka/kalessin/adam.html
[ Linux - OS/2
That was an excellent summary...
Essentially: 1) store heterogenous data in inode itself,
2) multiple file-name data streams,
3) multi-streams and file/directory distinctions vanish
#2 folks and #3 folks differ also by the de-association of files and their
sub-data: #2 wants tightly bound association (and variant notation) and #3
wants to expand the nature of "magic nodes" so they can lead *anywhere*.
Its basically a database problem, tho.
There are three types of data to consider in this batch:
* [volitile/user] per-user AND per-path/file data (prefs or notes)
* [storage/data] per-content/file data (apps, history, self-descriptions)
* [OS-level/fs] per-inode/file data (copy refs, access/perm data)
Note that a file has *three* data-forks already!:
A) -- its image of having a certain path (any links alter this)
B) -- its explicit details of inode/storage and OS perms/dates
C) -- its main contents of whatever format or nature
The separation is then simpler: paths, inodes and data-blocks,.
We seem to want to virus off a new niche within any one of these.
The NEAT IDEAS are as follows:
* alpha * (squeeze in some user-data relative to #C)
Adding on user-content hints sounds *very* nice to me. I am tired of
having to rely on a big user-fs set of details, before dealing with
data-fork #C. User specifications are not trivial or unimportant, really!
* beta * (auto-select many #C's via only one A tuple-selection)
Adding some means of making #C (content) adapt magically to kernel
information is a cute idea too. (i.e. nodename or user switching of sets
of files). Magically smart files are always nice to deal with. Of course
they are in fact *VERY* kludgey as well.
* gamma * (get #C to be smart on its own, but allow it to be back-compat)
Adding a way to make #C (content data) identify *ITSELF* in some fashion and
be as easy to access as #A or #B would be nice. Folks want to stuff this
data into data fork #B.
-----------------
For Idea Gamma first:
Make an inode data field (everyone groannnns) that contains *NOT* a bunch
of detailed data, but instead a smart-offset inside the file. The offset
leads to .... YOU GUESSED IT... A STANDARDIZED PATH! Okay maybe you
didn't. (this path string could be ended by any character other than
alphanums, ".", and "/", and so could safely exist as a C string in the
executible or merely be found at the start of a text script)
Call this path a "tag." No need for the offset to be standardized at some
point or another. However, if the data format cannot stand having these
"extra bytes," maybe put it at the beginning of the data blocks and shift
all user byte-offsets around it from inside the kernel. (another groan)
Anyway, this tagpath must start from root and lead to a program or some
file that is hereby purported to be a "usefulness extractor" for this file.
No wild requirements exist for what that tag refers to. If the original
file considers itself standardized, the path can lead to a standardized
"switchpoint" (symlink?) that leads to some standard application/handler.
chosen by the user. If not, then hopefully the file will get used in some
other way.
In order to use this inode-located path, one could run some dumb little generic
"launcher" program called "click" or "use" or something similar. This would
be what properly execs the file, or even maybe apply some system call to do
this?
For new or unknown files, the "file" command would finally get its lovely
little magic system to be **really** useful! It could detect or seek out the
appropriate "tag" somewhere within the bounds of the file, or assign it a
default tag. When done, it could set the inode offset properly. Now your file
is "tagged" properly.
To make it really really unixy: Let processes maintain this automagically!
Totally new data files could easily "inherit" the executible's own prefix
path if their creator had some possible inode-bit set or if it just said so.
In this way.. I could chmod-setup "/usr/ucb/vi" and create all kinds of files
when running it, that would respond to "vi" if ever I "clicked" on them (i.e.
they are vi-objects). If they were in fact made by someone else initially,
the other handler-path could remain "stuck" to the files just as well.
However, programs like tar or gzip, should avoid letting this happen when
merely extracting their files... as you can guess. It would make good sense
when compressing the files initially, but even then, these commands should lead
to "editing" or "managing" informative programs for the user.. and not merely
do their work.
Neat eh? Dynamic inheritance only requires *ONE* virtual-function table
pointer. Recognize one path somewhere in a file and Voila: pure and nearly
automagic Object-orientation with the cost of one inode-field!!!
-----------------
For Idea Beta:
Directories are nice puppies, even if generally inflexible.
If *ANYONE* wants to implement Magic Directories, then simply do the same
thing above with a "switchfile's" *contents* used as the appropriate
directory's appropriate file name.
- Demand the allowed switchfile be a final file: symlinks are read as data
- Demand the string NEVER start with / or traverse .. even once
(files *inside* can be symlinks, but a switchfile can't lead anywhere!)
- Demand the string be a string of only specific chars, else it's ended
(a misplaced /usr/dict/words won't suddenly cause the *kernel* to barf).
Then whatever fs or path you like can hold the "switchfile" for hundreds of
magical directories at once, each deciding their sub-choice when read.
Some optimization could be done to connect magic directories and their
switchfiles so that the switchfile actively changes (or "dirties" some cache,
maybe) its preferred targetfile. Of course, if switchfiles are located by
a path that follows anything wierd or dynamic, then they'll have to be
re-read every time, making it like a never-cached-symlink.
One last thing: since "switchfiles" can *never* contain absolute paths, and
"tags" must *always* have absolute paths, then a switchfile might as well
*ALSO* produce paths that allow directories to be a first-class object in
their own right. :-> (yes, doubly indirect, but why not allow one central
change of handler point for dozens of directories around)
(There you go, now you can type "setup /etc/ppp" in order to run your PPP
configurator. Type "setup /usr/X11/lib" to configure X.)
Squeezing this little bit of smarts into our files is *really* a useful idea.
I hope the problems with it (i.e. storing and possibly ignoring a path's space)
are pretty minimal. I've not looked into it much.
---------------------------
For Idea Alpha:
* Okay.. I am *NOT* for storing wildly unusual data *in* the inode. I want
my buffercache to be stuffed to the gills with lovely vnodes that never
get big or page in their data unless they REALLY have to. They are also
nice and "small" ideally.
* The directory data structure should not be opened up. Directories are able
to be fooled about their files (hard-links) and I like the ability to use
a HUGE read-only filesystem... so I won't have to do gymnastics to keep
Bad Things from happening within totally spotless directories. Volitile
data should stay home and directories might as well be read-only while the
file itself is writable.
Besides.. data is data. If many users or many views of it exist they
should all be happy on their own. Directories with hundreds of files are
meant to get ME to MY file inode and that's it. Custom info elsewhere.
Ergo... user-specific data can go somewhere much more special!!!
Howzabout this as an idea:
1) Make a kernel based file system "handler" or "server"
(can tolerate lots of dinky local mounts, easily connected/disconnected)
2) Have the new FS work from a *very* compact storage in a REAL file, with
read write access allowed. It might as well be a locked tar archive
file!
3) Allow each user their own little fs-userdata file and then they can "mount"
it themselves and each see their own little version of their own data
forks, (via the exact same path for crucially private resources or) via
each users own path, for their public resources.
4) Bingo.. a user-specific "shadow" file system for every file, that can be
accessed via an obvious root path.
(e.g. /rforks/me/usr/local/bin/netscape.icon)
(yet another another imaginary file-system groans everyone..)
But really... (hasn't the tar one been done already??)
The paths in this little virtual-FS don't *NEED* to be exhaustive. Just
store the paths where users put cute little info of whatever sort! Hash on
through to the data when a user-program asks for it. It should just be a
little string-lookup database system for a limited length of data field.
If more than that, they should store symlinks in *REAL* files somewhere
outside their little file-system.
Also.... if in fact their old and musty virtual-FS has lost track of a file
due to it being moved around by someone, or the sysadmin, or something, then
have it check a backup route before the file system is mounted: hang on to
the inode number and/or a check again for real "anchor files" thru the $PATH
the user started with. Perform some central fix-fs you want if lots of
stuff has been shifted around and users' preferences are being confused. A
good housekeeping chore once a week!
So what about useful centralized defaults for every bleedin application
everywhere for Joe User Of None Clueful Type???
Easy, have the applications also check this instead of /rforks/me or even a
/rforks/<username>:
/rforks/users/usr/local/bin/netscape.ad
Even this little file, found so a user benefits from the defaults or can find
them, could in fact be a rfork-symlink to some garshawful storage place like:
/usr/local/lib/netscape/app-defs/Netscape
(As for the fs-file to store these defaults, put it in /etc if you like :-).
Referring to your data in 8000 ways is what makes databases Relational.
(Now, to make a reverse-directional database so you can find out where the
buggers really are in a *real* directory, and can delete them).
Conclusion:
Unix fs's *ARE* a database system. It is able to do lookups and references
very quickly but only you ONLY do a lookup...
- via a strictly ordered n-tuple of non-null string keys (a directory path),
and
- must pass the locking and permissions system for all keys (inode perms)
and
- you happen to accidentally, circumstantially apply the proper object
handler for your environment and identity and machine and display..
Obviously .... to me... the last one is the only *inherent* flaw above. :->
// {if(me==chris)me->confuse(yu);} // DubleTawk+SinglThots+AntiFathe: UnRome II
### C>H> ### chrhas@auto-trol.com /////////////// {"Nietzsche is dead."-God} //