Bug 834717

Description of problem:

Symlinks that include a trailing / used to work (the / obviously
didn't mean anything, but didn't hurt anything either, and some appear
that way in the wild), and now they can't be traversed during file open,
but they still can be for listing or stat:

$ cat baz/bar
cat: baz/bar: Not a directory
$ ls -l baz/bar
-rw-r--r-- 1 jflack jflack 6 Jun 22 16:57 baz/bar


Version-Release number of selected component (if applicable):

This began after update to 2.6.18-308.8.2.el5

How reproducible:

Reliably. Seen for link targets on nfs4 filesystems, not on ext3, haven't
tried others.

Steps to Reproduce:
1. Create a directory on an nfs4 filesystem, and a file in it:

mkdir foo && echo hello >foo/bar

2. make a symlink to the directory with a gratuitous trailing /

ln -s foo/ baz

3. try to open / list / stat the file traversing the symlink:

ls -l baz/bar
cat baz/bar
  
Actual results:

-rw-r--r-- 1 jflack jflack 6 Jun 22 16:57 baz/bar
cat: baz/bar: Not a directory

Expected results:

-rw-r--r-- 1 jflack jflack 6 Jun 22 16:57 baz/bar
hello

Additional info:

Repeated / in a pathname are traditionally equivalent to one.
This still works if the symlink is not involved:

$ cat foo/bar foo//bar foo///bar
hello
hello
hello

It is only when the / is part of a symlink that the traditional
behavior has been broken.