Re: [Summary] Meta-data/filesystem-encapsulation

[Christopher Curtis <ccurtis ee fit edu>]

On Mon, 17 Aug 1998, Leareth wrote:

Is the enemy of my enemy my friend?  ;-)

> 	A: Have very good support for system's that chose not to use
> LD_PRELOAD, or the optional libc patch we provid as a side option, with
> good file rerecignization for broken links, and a per user database for people
> who don't have access to there sub system, and are on a system that does
> not support LD_PRELOAD(or they chose for some reason not to use it).

fyi: If I wasn't clear (as often seems to be the case) LD_PRELOAD would
only allow 'mv' to update any links to metadata needed, if needed.
Hacking libc is a really bad idea - if LD_PRELOAD isn't an option, the
better solution is to use GNU 'mv' or GNOME 'mv' (hopefully preferrably
GNU 'mv' would accept GNOME-patches).  I think if they ignore either of
these options (users can do LD_PRELOAD from .profile/.cshrc if they want
and the system supports it, or they can add /opt/gnome/usr/bin to the
front of their paths) then disassociation is deserved.  The only thing,
though, is that these options have to first be made available before we
can protect ourselves from orphaned data -- did you use our LD_PRELOAD?
Did you use the GNOME /usr/bin utils?  If these don't exist orphaned data
is going to be a reality, and that has nothing to do with saving data in
the filesystem or in an external database.

> static apps are, A: a bad idea for the most part(good for recovery tools though,

Also good for commercial apps.

... but, do static apps not run against LD_PRELOAD?  

--
Christopher Curtis               - http://www.ee.fit.edu/users/ccurtis
                                 - System Administrator, Programmer
Melbourne, Florida  USA          - http://www.lp.org/