mouse@collatz.mcrcim.mcgill.edu writes:

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

The general rule should be: don't change anything that isn't broken.

If anyone feels that symlinks really shouldn't have {whatever}. Then
make a new file type that follows these new rules. 

If this had actually been done, we wouldn't need programs like autoconf.


> 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 need to keep a uid in the directory entry.

> What do _you_ propose in answer to the POSIX problem, then?  

Any problems with POSIX should be solved the normal way: ignore them
and hope they go away.


> 1) Symlinks are full inode entities, with all the info showing through
>    when lstat() is done.

And why shouldn't they be?

>  1A) Attributes can't be changed.
>  1B) Attributes can be changed with chown(), utimes(), etc.
>  1C) Attributes can be changed with lchown(), lutimes(), etc.

According to general rule stated above, 1A or 1C. Neither will break
old code.

> 2) Symlinks are inodes or funny directory entries or maybe something
>    else, but they appear ownerless, timeless, etc.

What's the benefit? A more complicated filesystem.

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

The problem, AFAICS, it that it will break all current code.


| joda@nada.kth.se   | Everything's cool and froody.
| Johan Danielsson   |                          -ZB