Don Cragun wrote:
> 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.
>
That would seem to resolve the PATH_MAX question asked earlier since
the length interpretation is implementation dependent.
An interpretation change request assumes that we would want this to be
adopted as a standard, which may be desirable, but this proposal doesn't
rely on reparse data being used for local path resolution (at this time).
This proposal is intended to support reparse point aware services.
Regular applications should be unaware that the text is anything other than
a dangling symlink.
Alan
