In 2.1.xxx, a "lookup_dentry" call with "follow_link==0" will still
follow a final link if the pathname has trailing slashes. That is:
touch foo
ln -s foo foo-symlink
perl -e 'rename "foo-symlink", "bar-symlink"' # moves the symlink
perl -e 'rename "bar-symlink/", "bar"' # moves the underlying file
(Once again, GNU's "mv" does some hanky-panky that confuses the issue.)
IMO, this is a great feature. It let's us explicitly override the "do
not follow symlinks" semantics of any desired system call. And, if
the GNU utilities didn't so often get in the way, it would give the
end-user the same option. On the other hand, I assume it's
nonstandard, and it's a little disconcerting that (1) the technique
works on nondirectories instead of returning ENOTDIR or something;
(2) an "lstat" on "foo/" stats the underlying file; (3) possibly other
strangenesses I haven't thought of.
2.0.xxx does all sorts of weird things with trailing backslashes. I
don't have source handy, but it seems that "open" returns ENOTDIR, and
"rename"---for the source argument---returns ENOENT even when both
symlink and underlying file existed.
Kevin <buhr@stat.wisc.edu>