Bug 834717 - 2.6.18-308.8.2.el5 broke symlinks with end / on nfs
Summary: 2.6.18-308.8.2.el5 broke symlinks with end / on nfs
Keywords:
Status: CLOSED DUPLICATE of bug 814418
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.8
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-22 21:18 UTC by Chapman Flack
Modified: 2012-07-30 15:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-30 15:13:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Chapman Flack 2012-06-22 21:18:03 UTC
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.

Comment 1 Ondrej Vasik 2012-06-25 05:22:47 UTC
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 09:17:54 UTC
Likely a duplicate of:
Bug 814418 - NFSv4 symlink regression problem
see Bug 814418 comment 20

Comment 3 Steve Dickson 2012-07-30 15:13:50 UTC
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.