Re: readlink(1) behavior

[Jim Meyering]

Jim Meyering wrote:
> Eric Blake wrote:
>> According to Jim Meyering on 9/18/2009 4:47 AM:
>>> Assuming ln -s /nowhere dangling-symlink,
>>> New behavior:
>>>
>>>     $ ./readlink -fv dangling-symlink/
>>>     /nowhere
>>>
>>> Previous:
>>>
>>>     $ readlink -fv dangling-symlink/
>>>     readlink: dangling-symlink/: No such file or directory
>>>     [Exit 1]
>>
>> On one hand:
>>
>> ln -s dangling link => 0
>> stat dangling/ => ENOENT
>> stat link/ => ENOENT
>> mkdir link/ => 0
>>
>> the behavior is consistent - a single mkdir can create the lone missing
>> element in the (expanded) pathname.  If we really claim that -f implies
>> that a missing last element is acceptable if it can be created by the same
>> name, then that explains the new behavior.
>
> That sounds reasonable.
> Of course, non-creatable dangling links still induce failure:
>
>     $ rm -rf non-dir; touch non-dir
>     $ ln -s non-dir/file dangling
>     $ ./readlink -fv dangling
>     ./readlink: dangling: Not a directory
>
> It comes down to weighing the cost of a new option[*]
> and the risk that this change would break someone's script.
>
> Since changing our ability to detect a dangling symlink might be
> a security-related issue, I'm leaning towards keeping the existing
> semantics, just in case.  However, it's still nearly a toss-up.
>
> Dmitry, what do you think, now?

In the absence of any objection, I'd like to go with what
seems to be the easiest to explain/document/understand,
and not add a new option.

This seems like such an obscure corner that I think few (if any)
scripts will be affected by the change in readlink behavior.

Any other opinions?

Speak now...