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.
Thanks for report, but this has nothing to do with filesystem component - which just creates and owns basic system directories. As you mentioned it works correctly for ext3 and fails for NFS, I'll assign that to Steve Dickson and component to kernel.
Likely a duplicate of: Bug 814418 - NFSv4 symlink regression problem see Bug 814418 comment 20
I'm going to make this a dup of 814418... If it turns out not to be the case please feel free to reopen *** This bug has been marked as a duplicate of bug 814418 ***