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...
