[more on the symlink can-o'-worms]

> Apparently, POSIX is going to specify that most syscalls follow
> symlinks.  (as i recall, the exceptions are readlink, lstat, unlink,
> and rename.)

> The point of POSIX is to specify standard programming interfaces that
> people can use to write 'portable' code.  How would _you_ handle
> symlinks?

I would prefer to promote symlinks to full-fledged filesystem objects.
Whether POSIX should have allowed them to be funny directory entries
seems to me to be irrelevant to our discussion.

> One could argue that chown() (and similar functions) should be
> reverted to not follow symlinks...  So, then, how does one change the
> ownership (or whatever) of the things pointed to by the links?

The obvious answer, of course, is to make someone who wants to do that
do a readlink() first...or perhaps provide a call (syscall, library
routine, whatever) that takes a path to a symlink and returns the
linked-to path, iterated so that the last component is not a symlink.

> Whether or not you think they're 'well designed', there _already_
> exist file systems which on POSIX-conformant systems which support
> symlinks as directory entries, and any solution that's picked must
> sanely address the problems that symlinks create.

I see no reason why we have to be fully POSIX-conformant on this issue
to begin with (it seems to me that standards are optional, and that
ill-conceived or mis-written standards, or portions thereof, should be
ignored), and don't see any particular reason why POSIX conformance is
incompatible with making symlinks full filesystem entities anyway.

The problem is not large.  There are many syscalls that take pathnames;
specifically, open, link, unlink, chdir, mknod, chmod, chown, mount,
unmount, access, chflags, acct, revoke, symlink, readlink, execve,
chroot, swapon, rename, mkfifo, mkdir, rmdir, utimes, quotactl, statfs,
stat, lstat, pathconf, truncate, undelete; there are more (unmount,
ktrace, vtrace, nfssvc, lfs_*, and most of the socket calls) that are
not documented or which can take pathnames in only some circumstances.
But not very many of these are really trouble spots.  Some of them
already have specified dealings with symlinks (eg, open, readlink);
there are some more for which it would be completely insane to follow
(eg, unlink) or not follow (eg, execve) links.  There are only 19 calls
left, by my count, and most of them are easy, either because they
already take a flags argument that could have a bit added to control
terminal link following or because the question of whether to make them
follow symlinks simply degenerates to the question of whether symlinks
support a specific filesystem attribute.  A few use pathnames as names
for filesystems; a few more are administrative syscalls normally made
only by supplied programs.  A few more amount to "follow the link or
return EISLINK?" (eg rmdir).  The only ones that seem to me to need
thought are mount, link (both pathnames), and rename (target pathname).

If, as you say, POSIX specifies most calls to follow terminal symlinks,
I see no reason we can't add parallel calls a la lchown(); we wouldn't
need many - just one for each attribute-setting call, of which there
are only five, by my count: chmod, chown, chflags, utimes, truncate.
Except for utimes(), these already have f*() versions anyway, so l*()
versions would provide a pleasing parallel to stat/fstat/lstat.

Or - this is a tack I'm not sure I wouldn't prefer - we could ignore
POSIX at the syscall level, make most syscalls not follow terminal
links, and provide a -lposix with library routine wrappers to provide
fully POSIX behavior.  All we'd need is one more syscall, taking a
pathname, a syscall number, an argument number, and the rest of the
syscall arguments, and would expand the pathname and make the syscall.
If you are willing to ignore the resulting races, you could even do it
entirely in user-land without any new syscalls.

I'm really not sure POSIX conformance on the issue of syscalls
following terminal symlinks is worth the headache.  But then, I have
noticed I have a stronger tendency to ignore standards I dislike than
core does....

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu