Metadata, a complete, WELL DOCUMENTED, idea, and responce.

[Leareth <leareth geocities com>]

Ok, here are a few diagrams.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NORMAL, non metadata system.
__________                      _________
| LibC         | ----------| user apps |
^^^^^^^^^^^^                     ^^^^^^^^^^^^

Metadata enhanced system.

_____              _________                    _________
| LibC |------| metalib (1) |---------| user apps |
^^^^^^              ^^^^^^^^^^^                   ^^^^^^^^^^^
                            /\
                      ----------------
                      | Meta awear apps (2) |
                      ^^^^^^^^^^^^^^^^^^^^^

1> Where metalib is loaded useing LD_PRELOAD, and all apps are
auto "linked" against it at runtime, and any symbols that were linked
at compile time are over written by the symbols in any library listed in
the LD_PRELOAD statment. giveing you the chance to suply your own
version of std commands with hand written ones. Care must be taken
with this, as any symbols in your hand written library WILL over ride
thous in a app, or library with which it is linked. A very safe nameing
scheme must be adopted.

2> Apps the trully link(at compile time) with metalib, useing it's further
capabilitys to access & apply metadata.

Ok, now metadata is kept track of on a per filesystem basis, this is in
responce to a problem posed by a person mentioning NIS systems,
and how a database per user can become quite lossy.(per user was my
original design) As a consiquence, concidering nfs type systems, and
dynamic ip's + other problems, user names within the per filesystem
database must be username+ a VERY unique number stored in the users
home director, so that name conflicts do not ocure.(Imagin multiple system's
useing a NFS drive, and systems shareing the same user names...)

This simple means that metalib must access a suid binary to ensure
a secure interface(a binary that checks the validity of the library that is
calling it). to the file that stores metadata on each fs, so that arbitrary
users cannot mangle the metadata, but have access to that parts that
they should.

Metalib will use a small caching system, that does these checks, and tracks
the data listd below.

	A checksum(small, but reasonable unique), for each file opened.
	This is stored for purposes given lower.

	A file that is opened NEW, (eg, file didn't exist before), it is added
	to a list.

	A NEW file that is asking for a close gets checksumed against the
	list of the opend files + files that were open at the time.

	A cache of the checksum's are stored untill all NEW files that were
	opened while they were, are closed. Metadata is updated along the
	same lines.

	As "mv" is a direct system command, it can be directly over ridden
	and metadata handled easily.

	As "rm" is also a system command, it may be handled in the same way
	and metadata taken into acount when the NEW file list deems it safe.
	Deletion of course ocures immediately, just not for the metadata.

	As "(u)mount" is a system command as well(I belive...), it may be 
	tracked & metadata updateing can be done when a umount is caught
	if nessessary.

Now I think this pretty much covers it, but if anyone else see's any holes in
it, tell me. To the people that like the .info style metadata.... well for one
thing it can keep track of the files if there moved out side control library.
There are other good reasons agianst it, but thats the best, second best being I
hate file system cluter, and love setting metadata. The directory aproche being
100% appdata only, and not applying to metadata in anyway, I'll ignore it.

I hope to hear from anyone with comments on this soon.

Any spelling error are due to my rather lacking spelling skills, and ispell
being fraged...

--
Leareth <leareth@geocities.com>
-- You've got to lose, to know how to win.