Re: link(2) and symlinks
From: Gunnar Ritter
Date: Thu Mar 10 2005 - 13:16:09 EST
Andries Brouwer <aebr@xxxxxxxxxx> wrote:
> On Wed, Mar 09, 2005 at 03:14:36PM -0800, Nick Stoughton wrote:
> > Most Unix implementations behave in the manner specified by POSIX. One
> > notable exception is Solaris 8 (I don't know about later Solarises).
It's still the same on Solaris 10. /usr/bin/ln behaves like Linux, and
/usr/xpg4/bin/ln behaves like POSIX.
> > Would a patch to provide POSIX conforming behavior under some
> > conditional case (e.g. if /proc/sys/posix has value 1) ever be accepted?
> It sounds like a bad idea to have name resolution semantics dependent
> upon some external variable. The result would be that nobody could be
> sure anymore what the link() system call will do.
I second that.
> (Also, POSIX does not describe the kernel interface - it describes
> a C interface. It would be possible for a libc to arrange that a
> different link() routine was used.
> Use of personality(2) does not sound like a good idea.)
The Solaris implementation of the POSIX behavior is done mostly
in userspace, as running truss with /usr/xpg4/bin/ln shows. The
actual link system call seems to be always the same one, with a
Linux-like behavior. /usr/xpg4/bin/ln only invokes resolvepath()
(a realpath()-like system call) first.
> ((Maybe it would be beter to change POSIX here. Submit a defect report
> and make the result of hard-linking to a symlink unspecified.
> Since Linux and Solaris are non-POSIX here, programmers of portable
> programs cannot rely on POSIX anyway.
In the standards sense of portability, they can; the formally conforming
Solaris environment behaves as POSIX specifies, and Linux has never been
formally conforming to POSIX.1-2001 anyway.
> Moreover, the Linux/Solaris behaviour sounds entirely reasonable,
> preferable in fact above the POSIX behaviour.))
I personally agree, but I doubt our opinion matters much.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/