RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 916561 - Files cannot open symlinked directories? WHAT?
Summary: Files cannot open symlinked directories? WHAT?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nautilus
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Alexander Larsson
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-28 10:27 UTC by Matěj Cepl
Modified: 2015-11-19 08:33 UTC (History)
5 users (show)

Fixed In Version: nautilus-3.14.2-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 08:33:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
screenshot of the issue (85.12 KB, image/png)
2013-02-28 10:27 UTC, Matěj Cepl 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2236 0 normal SHIPPED_LIVE nautilus bug fix and enhancement update 2015-11-19 09:02:22 UTC

Description Matěj Cepl 2013-02-28 10:27:59 UTC 
Created attachment 703875 [details]
screenshot of the issue

Description of problem:
I accept I have a bit complicated structure of symlinks

matej@wycliff: ~$ ls -l rhprojekty
lrwxrwxrwx. 1 matej 500 16 Oct 24  2011 rhprojekty -> RedHat/projekty/
matej@wycliff: ~$ ls -l RedHat
lrwxrwxrwx. 1 matej 500 17 Mar  9  2010 RedHat -> Dokumenty/RedHat/
matej@wycliff: ~$ ls -l Dokumenty
lrwxrwxrwx. 1 matej matej 11 Jan  4 02:29 Dokumenty -> archiv/2013
matej@wycliff: ~$ cd rhprojekty/
matej@wycliff: rhprojekty$ ls -l 
total 12
lrwxrwxrwx. 1 matej matej   41 Jan 29 18:02 automation -> ../../../2012/RedHat/projekty/automation/
lrwxrwxrwx. 1 matej matej   46 Jan  7 17:27 beaker-job-XMLs -> ../../../2012/RedHat/projekty/beaker-job-XMLs/
drwxrwxr-x. 5 matej matej 4096 Jan  7 17:33 brasero
lrwxrwxrwx. 1 matej matej   34 Jan 29 19:09 dbus -> ../../../2012/RedHat/projekty/dbus
lrwxrwxrwx. 1 matej matej   45 Jan 29 19:09 dbus-automation -> ../../../2012/RedHat/projekty/dbus-automation
lrwxrwxrwx. 1 matej matej   40 Jan 29 19:09 dbus-sklad -> ../../../2012/RedHat/projekty/dbus-sklad
drwxrwxr-x. 4 matej matej 4096 Jan 28 17:46 eds
drwxrwxr-x. 3 matej matej 4096 Jan 29 18:07 freetype
lrwxrwxrwx. 1 matej matej   36 Jan  7 17:27 gedit -> ../../../2012/RedHat/projekty/gedit/
matej@wycliff: rhprojekty$ 

but so far no Linux application made a damn about it and everything worked as it should.

Then today I tried to be a good Gnome user and use Files for my file managing needs. So I went to my rhprojekty folders and clicked on gedit symlinked folder and got the attached error message.

Version-Release number of selected component (if applicable):
nautilus-3.6.3-5.el7.x86_64

How reproducible:
100%

Actual results:
Cannot opened the directory to work on it.

Expected results:
Symlink is same as the real thing as everywhere else in the Linux world.
Comment 2 Matěj Cepl 2013-02-28 10:59:18 UTC 
Created attachment 703879 [details]
output of strace -o nautilus-strace.txt -f nautilus
Comment 4 Tomáš Bžatek 2013-02-28 13:23:55 UTC 
(In reply to comment #3)
> Created attachment 703881 [details]
> output of strace -o nautilus-strace.txt -f nautilus (after nautilus -q)

Unfortunately there's not much useful information to see, however few remarks:

> 8755  openat(AT_FDCWD, "/home/matej/RedHat/projekty/gedit", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC <unfinished ...>
> 8755  <... openat resumed> )            = 23

> 8755  lstat("/home/matej/RedHat/projekty/gedit/README",  <unfinished ...>
> 8755  <... lstat resumed> {st_mode=S_IFREG|0664, st_size=25, ...}) = 0

Both calls succeeded, no problem reported.

However:

> 8773  lstat("/home/2012/RedHat/projekty/gedit",  <unfinished ...>
> 8773  <... lstat resumed> 0x7ffa66938960) = -1 ENOENT (No such file or directory)

This clearly takes wrong path. And this is also all that can be seen from strace, the code is wrong somewhere. Needs further debugging.

stat outputs from Matej:
> matej@wycliff: ~$ stat -L rhprojekty/gedit
>   File: ‘rhprojekty/gedit’
>   Size: 4096       Blocks: 8          IO Block: 4096   directory
> Device: fd07h/64775d Inode: 6037511     Links: 4
> Access: (0775/drwxrwxr-x)  Uid: ( 1000/   matej)   Gid: ( 1000/   matej)
> Context: unconfined_u:object_r:user_home_t:s0
> Access: 2013-02-27 16:29:07.932579060 +0100
> Modify: 2013-02-26 16:02:40.402044941 +0100
> Change: 2013-02-26 16:02:40.402044941 +0100
>  Birth: -

> matej@wycliff: ~$ stat  rhprojekty/gedit
>   File: ‘rhprojekty/gedit’ -> ‘../../../2012/RedHat/projekty/gedit/’
>   Size: 36         Blocks: 0          IO Block: 4096   symbolic link
> Device: fd07h/64775d Inode: 3803126     Links: 1
> Access: (0777/lrwxrwxrwx)  Uid: ( 1000/   matej)   Gid: ( 1000/   matej)
> Context: unconfined_u:object_r:user_home_t:s0
> Access: 2013-02-28 11:16:25.410761499 +0100
> Modify: 2013-01-07 17:27:34.186474870 +0100
> Change: 2013-01-07 17:27:34.186474870 +0100
>  Birth: -

Also got "gvfs-info rhprojekty/gedit/" output and that's correct as well, standard::content-type: inode/directory
Comment 5 Alexander Larsson 2013-03-01 09:50:21 UTC 
Ugh, this is tricky

I reconstructed your hierarchy inside /home/alex/test_nautilus

The problem happens when nautilus calls
nautilus_file_get_symbolic_link_target_uri() for the file
 /home/alex/test_nautilus/rhprojekty/gedit
 which it knows is a symlink with the contents 
 ../../../2012/RedHat/projekty/gedit

That starts with constructing the parent of the file, i.e. 
 /home/alex/test_nautilus/rhprojekty
and then calls g_file_resolve_relative_path() with the parent path and the symlink value.

Just concatenating the two gives us:
/home/alex/test_nautilus/rhprojekty/../../../2012/RedHat/projekty/gedit

But resolve_relative_path is an i/o free operation that just "concatenates" paths. So it ends up removing the 3 ".." by deleting the previous 3 directories.
Ending up with 
/home/2012/RedHat/projekty/gedit
which is wrong.

Its interesting to note that other things get this wrong too. Witness:

cd /home/alex/test_nautilus/rhprojekty/../../../2012/RedHat/projekty/gedit
$ pwd
/home/alex/test_nautilus/archiv/2012/RedHat/projekty/gedit

Gets it right, but:

cd /home/alex/test_nautilus/rhprojekty/../../..
$ pwd
/home

Gets it wrong.

I guess nautilus_file_get_symbolic_link_target_uri() needs to do a full symlink expansion of the parent GFile before calling resolve_relative_path. We should probably have a helper for that in gio too, as that is a somewhat complex operation that is easy to get wrong.
Comment 6 Matěj Cepl 2013-03-03 09:12:11 UTC 
(In reply to comment #5)
> Just concatenating the two gives us:
> /home/alex/test_nautilus/rhprojekty/../../../2012/RedHat/projekty/gedit
> 
> But resolve_relative_path is an i/o free operation that just "concatenates"
> paths. So it ends up removing the 3 ".." by deleting the previous 3
> directories.
> Ending up with 
> /home/2012/RedHat/projekty/gedit
> which is wrong.

Yeah, because that's just wrong algorithm. If you look at POSIX spec, then you would find out (as I did) that symlink is relative to the true expanded directory. So, in this case, we should go to

readlink(/home/alex/test_nautilus/rhprojekty/) + \
    "../../../2012/RedHat/projekty/gedit"

(readlink being a functional equivalent of readlink(2)).

If you don’t do the readlink() part, you just won’t get it right.

> I guess nautilus_file_get_symbolic_link_target_uri() needs to do a full
> symlink expansion of the parent GFile before calling resolve_relative_path.

Yes, I think so.

> We should probably have a helper for that in gio too, as that is a somewhat
> complex operation that is easy to get wrong.

Well, it’s just one glibc call, isn't it?
Comment 7 Alexander Larsson 2013-03-04 09:41:21 UTC 
Symlink may point to another symlink, and that one maybe be in another symlink parent, etc. See expand_all_symlinks() in glocalfile.c, although we want to implement that via file to allow e.g. symlinks in a sftp mount too.
Comment 8 Matěj Cepl 2013-03-04 10:39:30 UTC 
(In reply to comment #7)
> Symlink may point to another symlink, and that one maybe be in another
> symlink parent, etc. See expand_all_symlinks() in glocalfile.c, although we
> want to implement that via file to allow e.g. symlinks in a sftp mount too.

I thought readlink(2) recursively expands *all* symlinks, doesn’t it? At least readlink -f (bash command) does.
Comment 9 Alexander Larsson 2013-03-04 15:02:57 UTC 
No, that would not make it impossible for e.g. ls to see the inbetween links in the multi-link scendario (such as the above).

readlink -f is a full canonicalize operation and is not what the syscall does.
Comment 10 Matěj Cepl 2013-03-04 16:42:16 UTC 
(In reply to comment #9)
> No, that would not make it impossible for e.g. ls to see the inbetween links
> in the multi-link scendario (such as the above).
> 
> readlink -f is a full canonicalize operation and is not what the syscall
> does.

Sorry, then I meant readlink -f operation, not readlink(2).
Comment 11 RHEL Program Management 2014-03-22 07:00:27 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 12 Matěj Cepl 2014-10-08 13:34:00 UTC 
I cannot reproduce with Fedora 21, not sure about RHEL-7.1, I haven't tested it there and I don't have the setup anymore.
Comment 13 Matěj Cepl 2014-12-05 09:12:00 UTC 
(In reply to Matěj Cepl from comment #12)
> I cannot reproduce with Fedora 21, not sure about RHEL-7.1, I haven't tested
> it there and I don't have the setup anymore.

I CAN reproduce this very well with nautilus-3.8.2-10.el7.x86_64
Comment 15 Matěj Cepl 2015-05-13 10:18:20 UTC 
Yes, this seems to be fixed with nautilus-3.14.2-1.el7.x86_64 ... cannot reproduce the same reproducer anymore.

THANK YOU!!!
Comment 17 Martin Simon 2015-08-31 10:42:40 UTC 
According to comment 15 and verification on nautilus-3.14.3-3.el7, the bug seems to be fixed. The reproducer is linked in TCMS and is a part of standard test plan.
Comment 18 errata-xmlrpc 2015-11-19 08:33:54 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2236.html
Note You need to log in before you can comment on or make changes to this bug.