In article <199511240749.BAA09079@solutions.solon.com>,
Peter Seebach  <seebs@solon.com> wrote:
> >> *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.

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.

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

Sigh.  READ the proposal again.  ALL of the processing is avoided if
unless the fs is mounted with a special flag.  Testing the flag should
be just a test and a branch (maybe even just a branch, depending on the
cpu and what flags are left over and the arrangement of the code).  Only
those of us who want the magic features have the overhead.  (Also,
you've missed something else in the proposal, which is that the magic
name doesn't have to start a component).

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

No, it doesn't.

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

I don't know, one could argue, that stdio buffers are also similar in
theory and should be merged into the VM/buffer cache as well. I think
that's silly, but it can be argued for extension from VM/buffer cache
proposals. Therefore, according to your logic above, since the VM/buffer
cache proposals, even if sensible, can lead to outrageous proposals, it
must be bad.

Once again you're arguing against the proposal at hand because ANOTHER
proposal is bad.

I can asvae you another argumeht as well: "If it becomes included, then
soon it won't be optional". Which is false... look at kernfs and procfs,
which have been included for a very long time and are still entirely
optional.

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

Doesn't work that way... if it shows up in directory entries AT ALL,
programs will try to use it, figure out what it is, etc. And for the new
object to be useful, it would then need special support in ls (so they
could be examined), tar/dump/resore (so they can be backed up), fsck,
and many more.

> >This sounds like the arguments against symlinks.
> 
> I still have my doubts about symlinks and their implementation, although
> I admit to finding them convenient.

And convenience is the argument for magic names.

At any rate, magic names are useful to many of us, entirely optional
with very little size and even less speed cost for those who don't use
them. I think they should be included (moduluo a few changes to make the
magic names a bit more standard).