Alan,
I'm resending this since I used the wrong alias for PSARC and none of
this discussion has been recorded in the formal case log.
Please find additional comments below...
Alan.M.Wright wrote:
> 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
Note that Joerg's sample find command is commonly used by system
administrators on some systems to get rid of dangling symlinks on their
systems. He was just pointing out that symlinks containing reparse data
will be removed by this common script.
I missed the fact that you never expect one of these symlinks to be
resolved on a[n] [Open]Solaris system. If that is true, you won't need
an interpretation to keep a verification suite from saying the system
does not correctly process symbolic links if you ever plan to get a UNIX
brand or POSIX certification for Solaris next.
The comment in the quote about PATH_MAX is that the standard allows
PATH_MAX to be unlimited. Solaris systems do have a pathname length
limit and the length is limited to PATH_MAX bytes. In cases where
symlinks will not be resolved, there need not be any relationship
between the maximum number of bytes held in a symlink and PATH_MAX.
The only part that is implementation dependent is whether there is a
maximum pathname length or not.
- Don
