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

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

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
for procfs ?).

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

For people who think the kernel is bloated (which it might be by PDP-11
standards) then we should be careful to make sure that they *can* reduce
the kernel down in size by removing all the "modern" features. But, as
an example, remember if you write the equiv. of ps for procfs, is someone
removes procfsthen bye bye ps. Etc Etc Etc.

I am still in favour of magic links.

Regards,
-- 
Peter Galbavy                                           peter@wonderland.org
@ Home                                                 phone://44/973/499465
in Wonderland                              http://www.wonderland.org/~peter/
                               snail://UK/NW1_6LE/London/21_Harewood_Avenue/