Bug 916561
Summary: | Files cannot open symlinked directories? WHAT? | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Matěj Cepl <mcepl> | ||||
Component: | nautilus | Assignee: | Alexander Larsson <alexl> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 7.0 | CC: | alexl, dking, mclasen, msimon, vbenes | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | nautilus-3.14.2-1.el7 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-11-19 08:33:54 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Created attachment 703879 [details]
output of strace -o nautilus-strace.txt -f nautilus
(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 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. (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? 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. (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. 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. (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). 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. 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. (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 Yes, this seems to be fixed with nautilus-3.14.2-1.el7.x86_64 ... cannot reproduce the same reproducer anymore. THANK YOU!!! 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. 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 |
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.