Paul Eggert <yyyyyy@xxxxxxxxxxx> wrote, on 16 Mar 2005:
>
> > I believe (those who were there can correct me if I'm wrong) that the
> > intent of the original specification was to allow both traditional
> > Unix implementations, which stored symbolic links in special files,
> > and other implementations which treated symbolic links as special
> > directory entries.
>
> If that was the intent, then the POSIX specification for link()
> doesn't capture it, since the spec currently disallows the traditional
> Unix implementation of link() that allows hard links to symlinks.
It only disallows link() from making hard links to symlinks. It doesn't
disallow the implementation of symlinks as special files.
Also, it explicitly allows pax to create hard links to symlinks on
systems that support them.
> Was it intended that POSIX disallow traditional Unix implementation
> behavior here? I don't see anything in the rationale about this.
I don't know the exact history of symlink standardisation, but my
guess is that this decision was made before symlinks went into POSIX,
and POSIX.1a just based its symlink additions on SUSv1 (or a draft
of SUSv1 if POSIX.1a got going before SUSv1 was published in 1994).
The wording of the symlink part of the pathname resolution rules is
identical in POSIX.1a and SUSv1.
The SUSv1 requirements may have been based on an earlier standard
(perhaps SVID?) or the rules may have been decided for SUSv1.
In any case, the requirement for link() to follow symlinks has been
enforced for all UNIX(tm) certifications over the last 10 years
(UNIX95, UNIX98 and UNIX03).
--
Geoff Clare <yyyyyyy@xxxxxxxxxxxxx>
The Open Group, Thames Tower, Station Road, Reading, RG1 1LX, England
|