Bug 834717 - 2.6.18-308.8.2.el5 broke symlinks with end / on nfs
2.6.18-308.8.2.el5 broke symlinks with end / on nfs
Status: CLOSED DUPLICATE of bug 814418
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Steve Dickson
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2012-06-22 17:18 EDT by Chapman Flack
Modified: 2012-07-30 11:13 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-30 11:13:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chapman Flack 2012-06-22 17:18:03 EDT
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

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

It is only when the / is part of a symlink that the traditional
behavior has been broken.
Comment 1 Ondrej Vasik 2012-06-25 01:22:47 EDT
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.
Comment 2 Jan Stancek 2012-06-25 05:17:54 EDT
Likely a duplicate of:
Bug 814418 - NFSv4 symlink regression problem
see Bug 814418 comment 20
Comment 3 Steve Dickson 2012-07-30 11:13:50 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.