Re: readlink(1) behavior

[Jim Meyering]

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?

Jim


[*] Documenting the subtle difference won't help make the
existing options any more understandable.