>In article <199511231858.MAA05433@solutions.solon.com>,
>Peter Seebach  <seebs@solon.com> wrote:
>> That's what HP says about cdf's, and all they did was break find, cpio,
>> tar, and the like, and get abused.  I never saw them do a whole lot of
>> good.

>But CDFs are different. If you want to argue against magic components,
>fine, but how about arguing on their own mertis (or lack thereof) rather
>than some other scheme's? Arguing that magic components are bad because
>CDF is bad is a strawman.

Mostly - however, the thing that makes CDF's so bad is that they look
*almost* exactly like a normal file of a known sort.  (For those not
familiar with the monstrosity: A CDF is a directory with the setuid
bit.  If you try to open it, you get the file in it that first matches
one of a set of environmental details, or ENOENT.  To access it, you
use "name+" where name is the real name of it.)

This is what I dislike about magic symlinks - they *look* like a normal
link, but aren't.  Code that, for any reason, tries to follow symlinks
will fail miserably for no good reason.

>> *what* special case processing?  I don't see any yet.

>Uh, how about symbolic links? Which, incidentally, broke a lot of
>things. I've never seen breakage of magic components under AFS (though
>AFS breaks some things for other reasons)

Symlinks are no more a "special case" than directories; but I do
see your point.  I guess, I don't object as much to a new type of file as
I do to an extension to an existing one.

>> But mostly, why should we charge every user of every system everywhere
>> *anything* for this feature?

>Could be said for almost any feature.

And should be, lest we become Ada or Windows NT.  We should be sparing
with features, even good ones, that are better addressed in userland than
in the kernel.  The kernel should *shrink*.

>The processor time has got to be quite negligable. I don't think two
>more instructions (probably) per uncached lookup is going to be
>really significant. Especially compared to the overhead of the
>alternatives.

More than that, I'd think; for *each* element of the symlink, you have to
see if it starts with an @.  (AFAIR; I haven't got the proposal right
next to me.)  If it does, you need to start looking for it in a table.

Still, not that great, but it applies to people not using the feature.

>> 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.

>So you're arguing for something *more* like CDF's???

No; I'm arguing for something that will *not* show up as an existing
file type, so programs will be less likely to think they know what's
happening.

>> I just dislike the idea of putting more clever awareness into symlinks.
>> What next - environment variables?  Inline tcl or perl?  Hmph.

>Absolutely right. And a merged VM/buffer cache is bad becauase next it
>will lead to calls for merged stdio buffers as well, right?

No.  The merged cache simplifies (in theory, if not practice :) ) by
replacing two attempts to do something with one, bringing together
like functionality.

>> Of course, I'm a bit of a purist; I still think that the net should be
>> mounted as a filesystem, and that ifconfig should just echo commands
>> to the special files that read them.  The filesystem model is a great
>> beauty, and I don't think we should fill it with cruft for short term
>> convenience.

>This sounds like the arguments against symlinks.

I still have my doubts about symlinks and their implementation, although
I admit to finding them convenient.

But it *bothers* me that a file can be present, be statable (with lstat,
anyway), be found by readdir(), and get ENOENT on an open.  lstat is
pretty bad in and of itself, although the necessity, in context, is
clearly there.  I just think it speaks ill of the construct that it
requires a second nearly-identical system call.  (And yes, I feel it
would make more sense for mknod to create normal files, rather than
having mknod for specials and creat/open for normals, not to mention
symlink.  I think mknod should do all making of nodes, and should be
sufficiently generic to handle the various cases.)

I don't expect most of this to happen, mostly because Unix is already
out there.  But I would like to see future potential problems of the
same sort avoided.

-s