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

> 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

  If this is a voting, mine is: 2, 1A, 1C (never 1B)

  I prefer to think symlinks as a "special" pseudo hard link.  ANY
references to the link SHOULD be really done to the file.  It only
purpose is to resolve cross-device linking, so should as most as
possible emulate hard link operation.

  Any operation direct to the symlink could be thought as a special
case, and so, can have any special behavior.  Even having no owner or
being implemented as an special directory entry.  And this is case 2.
I can see no problems with this that does not also happen with hard
link.  (But I can be wrong, of course... :)

  Just my humble opinion,

					Jonny

--
Joao Carlos Mendes Luis			jonny@coe.ufrj.br
+55 21 290-4698 ( Job )			jonny@adc.coppe.ufrj.br
Network Manager				UFRJ/COPPE/CISI
Universidade Federal do Rio de Janeiro