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.