> I don't like the idea of losing kernel space and processor time to this
> without more study of what we're trying to accomplish, and how we want
> to go about it.
> 
> A new type of file, which looks like a symlink, but has extra frills,
> might make more sense; we already have established that new file types
> will show up.

*chuckle*  did you actually _look_ at the implementation i provided?
did you look at what it takes to, say, implement a new inode type?
The latter is a fair bit more, and requires changes in more places...

The biggest win in the sample implementation that i provided -- and
that's all it is, provided in the hope that somebody would find it
useful -- is that it works on _all_ file system types, with a very
small overhead (one compare, when processing symlinks) for file
systems that don't have it enabled.

If you're going to argue costs, consider the cost of what you think
might be 'sensible'.


cgd