GNOME Bugzilla – Bug 702301
Symlinks are being expanded
Last modified: 2018-03-13 21:45:32 UTC
If I have a symlink /home/osmo/foo that points to /mnt/something/foo and I use nautilus to browse from my home folder, the path visible on the path bar is suddenly expanded to the target path. This makes navigation difficult since using Ctrl+Up one ends up in an unexpected and often unuseful place. Ctrl+Left navigates to the correct place, but nautilus forgets which folder was selected. In 3.6 and earlier versions as far back as I remember symlinks have not been expanded. The whole point of symlinks often is to hide some complexity, e.g. files split across multiple physical disks. There's a similar bug report from 11 years back when a similar change was made, but then reverted. https://bugzilla.gnome.org/show_bug.cgi?id=73937 Looking through the git log the only possibly relevant entry I found was mime-actions: https://git.gnome.org/browse/nautilus/commit/?id=fe1965f2cafc4616caaea0ae048bf1ff5c8975f5
(In reply to comment #0) > Looking through the git log the only possibly relevant entry I found was > mime-actions: > https://git.gnome.org/browse/nautilus/commit/?id=fe1965f2cafc4616caaea0ae048bf1ff5c8975f5 This is the problem. I recompiled nautilus with this commit reverted and symlinks work as expected again.
Why is this still unconfirmed? It's clearly a bug (for some really annoying) and the source of the problem has even been posted. Launchpad link: https://bugs.launchpad.net/ubuntu/+bug/1184720
I think we have to confirm it ourselves. This bug indeed breaks the powerfull linux symbolic links, and degrades them to Windows 95 style shortcuts.
This bug occurs also in versions
This is still unresolved. The offending bug that prompted the change is https://bugzilla.gnome.org/show_bug.cgi?id=686465, which shouldn't be described as a bug in nautilus, given that it is and should be Linux default behaviour. Symlinks are not Windows shortcuts, we have .desktop files for that. Comment on that issue if you think the change should be reverted. Cheers
I too can confirm that reverting that commit fixes the issue... For those who want to confirm the bug by reverting said commit, here's what I did on debian testing (jessie): # clone and fix nautilus 3.8 git clone git://git.gnome.org/nautilus cd nautilus git checkout gnome-3-8 git revert fe1965f2 # install dependencies (may vary on other systems -> run ./autogen.sh and install the packages that are not found) sudo apt-get install gnome-common libglib2.0-dev gtk-doc-tools libexif-dev libexempi-dev libgtk-3-dev libgail-3-dev libgnome-desktop-3-dev libxml2-dev libx11-dev libnotify-dev gsettings-desktop-schemas{,-dev} # compile and install in local folder (can be anywhere you like) mkdir $HOME/local ./autogen.sh --prefix=$HOME/local make && make install # run nautilus $HOME/local/bin/nautilus # test to see if it's fixed Hope I can help with that Cheers
Thanks. Is there a ppa with a fixed nautilus yet?
Please revert. The current behavior is so annoying.
This behaviour breaks completely the user view of the file system, is very important to be fixed. For example, "my_files/docs" leads to "/mnt/HD-01/users/teachers/name/docs", something completely absurd. It also breaks our confidence, because is a very deep change without any previous warning or option. I really ask you, please, to fix as soon as possible.
I have a similar configuration as gustavo. My home directory is full of symlinks to various cloud providers. This change in behavior is completely against the linux symlink behavior. I second/third, ++, etc. any efforts to revert to the original behavior (and linux standard) of not dereferencing symlinks.
I too would like to see this reverted to the old behaviour. Symbolic links should be transparent.
I strongly support reverting this, it makes Nautilus unusable for me (and I temporarily switched to another less integrated solution, mostly because of this) This also breaks behavior of some applications, and only removes flexibility without adding any feature: while applications wanting to dereference links were able to do it, now applications that don't want to cannot do anything since they don't even know what URI the user actually wanted to open. For example, EOG allows to browse the images in the directory containing the opened pictures (go to next/prev image in the directory). Since this change, when opening an symlink from Nautilus, EOG browses the directory containing the physical file, not the one containing the symlink. This is an highly unexpected and unwanted behavior, and is extremely annoying since it makes many symlinks useless. And as noted above, EOG could not do *anything* about this, because it has absolutely no way to know what URI the user actually wanted to open. Finally, even if #686465 was considered as a bug (I don't think it is one, but apparently some people do) it has little to do with Nautilus. GEdit can "fix" it if wanted, without breaking other apps in the process.
I reverted this now in gnome-3-12 and master. Sorry for the confusion.
I just tested master and it is indeed fixed, thank you very much!
@Cosimo: maybe it would make sense to revert in 3.10 as well (we are at least going to backport that commit to the 3.10 serie for Ubuntu)
Good idea - I reverted it in 3.10 as well now.
thanks
(In reply to comment #16) > Good idea - I reverted it in 3.10 as well now. Version 3.8 is also affected (this report was specifically for 3.8.x), can you backport as well?
Done.
Thanks man
*** Bug 720463 has been marked as a duplicate of this bug. ***