2009/387 [Pathname Reparse Points]

[Don Cragun]

On Fri, 10 Jul 2009 15:06:29 -0500 Nicolas Williams wrote:
> On Fri, Jul 10, 2009 at 12:36:02PM -0700, Garrett D'Amore wrote:
>> Nicolas Williams wrote:
 ... ... ...
>
> Also, I'm not sure that apps that read symlinks should have any
> expectations that the contents of a symlink will be a filesystem path.
>
> Nico

The standards place no requirements on what can be stored in a symbolic
link as long as the symlink is never used for pathname resolution.
However, when a symlink is used for pathname resolution, what is
being proposed here does not conform.  The standards say the contents
of the symlink replace the filename of the symlink and resolution
continues on the resulting path.  (I'm ignoring the exceptions for
resolving access to the symlink itself since they aren't important
to this discussion.)

Given that there is existing practice supporting other behaviors here,
it shouldn't be hard to file an interpretation request to allow alternative
symlink processing, but explicit text for the changes to the definition of
pathname resolution would be required to get a successful interpretation
and have the correct wording appear in the next revision of the standards.

 - Don

PS  The paragraph in the standard that would have to change to allow
    this can be found on P112, L3026-3031 of the 2008 version of the
    Single UNIX Specification and the IEEE and ISO POSIX standards
    where it currently says:
        "In all other cases, the system shall prefix the remaining
         pathname, if any, with the contents of the symbolic link
         If the combined length exceeds {PATH_MAX}, and the
         implementation considers this to be an error, errno shall be
         set to [ENAMETOOLONG] and an error indication shall
         be returned. Otherwise, the resolved pathname shall be the
         resolution of the pathname just created. If the resulting
         pathname does not begin with a <slash>, the predecessor
         of the first filename of the pathname is taken to be the
         directory containing the symbolic link."
This is found in the definition of the General Concept "Pathname
Resolution" in subclause 4.12.