In article <199511241916.TAA26102@alice.wonderland.org>,
Peter Galbavy  <peter@wonderland.org> wrote:
> > I think new types of files are MORE likely to cause breakage and lots of
> > adjustments to utilities (tar, dump, fsck, ls...) that small changes to
> > existing ones.
> 
> In the case of tar, I would not want my symlinks followed unless
> I said so as a command line option. But in the general sense, if

My point is that tar would need no changes to back up magic links, while
if a new inode type was introduced it would break.

> this is done, we need to then either modify readlink() or add a
> new function/macro that allows translation or not within utility
> programs. An extra arg to readlink() maybe - I find this messy and
> it is one of the major dangers pointed out in "Writing Solid Code".

This is a big problem I overlooked in chris's proposal. I started to
implement nami-level magic names at one point (got it done for
everything but nfs), but it has the problem of having to be implemented
in every blody filesystem, and in some that's a real pain (nfs).

I understand that Lites has magic names or symlinks. Anyone know which,
and how they are implemented?

It occurred to me that a new filesystem might be the answer... sort of
a modified nullfs that did the magic expansions. It would be mounted
in-place over a filesystem. The problem with this is that it can't be
there at root mount time, which is one of the really useful cases.
Perhaps there could be a mount option (like magiclinks) that would
automatrically mount a magicfs over the mounted fs. I don't know enough
about the 4.4 vnode system (the stuff I did with John Brezak was before
the 4.4 integration) to know what the potential pitfalls of this would
be.

> Unfortunately. kerfs and procfs could only *ever* be useful if you
> could rely on them being present. This goes for magic link options
> too. Unless an "option" is there by default then no one will use
> it except very locally. Software will not be written for it (ps

But magic names are really only useful locally anyway, even if they're
mandatory. They're a feature to be used by the system administrator as
s/he sees fit, or for specific cases where they can be forced manditory
(install kernels, etc). Software *shouldn't* depend on it, in general.
And doesn't need to.