> Points here:

> 	* symlink()/readlink()/lstat() are truly necessary, if you're
> 	  installing symbolic links.

lstat() is not necessary if you just define stat() to not follow links,
and then let people readlink() the link if they want the effect of the
current stat().  (Of course, this flies in the face of lots of current
tradition; I don't want to be taken as suggesting that this actually be
done.)

> 	* chown() as far as I could tell never affected the symlink
> 	  itself, although if, as you say, ownership were to be
> 	  significant, we'd need lchown().

> 	* lchmod() would not be necessary, since modes on a symlink are
> 	  never relevant.

By why aren't they?  It would make perfect sense, to me, for the r
permission to control who can readlink() the link and x to control who
can follow it during a normal path walk.  (No reasonable meaning for
the 07222 bits comes to mind.)

> #: My vote is to fix the sticky-bit hack, so that:
> #: 
> #:     -- A user can't make a hard link from a file he doesn't own into a
> #:     directory where sticky-bit access applies.
> #: 
> #:     -- A user can't make a symbolic link in a directory where sticky-bit
> #:     access applies.
> 
> Both of these are absolutely silly, as they place unnecessary restrictions
> on potentially necessary operations.

It's either that or have people able to create things in sticky
directories and then be unable to remove them.  Or else keep creator
information for links, which would be a _major_ filesystem change.

> You *can* find all the hard links to a particular file, [by
> exhaustive search of the relevant filesystem].

> You will also have a more difficult time locating all the symbolic
> links to a particular location -- short of running "find . -type l
> -ls | grep location", you're out of luck.

You're in the same situation with hardlinks - you have to do exhaustive
search of everywhere the link could be.  Hardlinks just make it a
little easier because the other links are known to be on a specific
filesystem.

[In summary]
> Either leave symlinks as they were or fragment the inode for the
> symlink purposes, but stuffing information into the directory entry
> is an MS-DOS solution to a system deserving of a more elegant one.

What do _you_ propose in answer to the POSIX problem, then?  I've been
able to see only a few solutions:

1) Symlinks are full inode entities, with all the info showing through
   when lstat() is done.
 1A) Attributes can't be changed.
 1B) Attributes can be changed with chown(), utimes(), etc.
 1C) Attributes can be changed with lchown(), lutimes(), etc.
2) Symlinks are inodes or funny directory entries or maybe something
   else, but they appear ownerless, timeless, etc.

All of these have problems.  As I see them:

Anyone who's been paying the least bit of attention to current-users
recently knows something of the problems with (2); they are mainly
sysadmin frustration (who created that bleedin' link, and when?) and
ill-defined interactions with sticky-bit directories.

(1A)'s problem is mainly a sort of feeling that "if it's there, it
should be settable".  This relates to things like root moving directory
hierarchies with tar and such, including restoring symlink owners.

(1B)'s problem is, as far as I can see, mainly that it is contrary to
that POSIX draft that people have been talking about.

(1C)'s problem is the accretion of yet more arcane special cases and
special-purpose syscalls.

My personal order of preference for these solutions is 1B, 1C, 1A, 2.
It might be possible to persuade me to switch around the subcases of 1,
but I really don't like 2.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu