After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652944 - enhanced symlink handling
enhanced symlink handling
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
3.0.x
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on: 68266 115805 308437 358205 581830 604572 607193 614239 622789 623124 623580 652948 675944
Blocks:
 
 
Reported: 2011-06-19 14:29 UTC by chrysn
Modified: 2021-06-18 15:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description chrysn 2011-06-19 14:29:54 UTC
while nautilus is basically capable of creating and displaying symlinks, its overall symlink support could be improved. this bug is created to track the various fields of issues around the topic -- once they are fixed, this bug can be closed and nautilus will have much better handling of symlinks.

issues mainly revolve around dereferencing symlinks (especially when copying), details of symlink creation (absolute vs relative); additional related issues are displaying symlink details and when to traverse symlinks.

there are also suggestions to include .desktop (/.lnk?) files in these considerations.

the bugs affected are (listing all i find here until i figure out how dupes are handled here):

* "i want symlinks to dereference {when copying to unsupported filesystems, when copying to removable devices, as a general option}": #308437, #581830, #623580, [rh201855]
* display symlink targets in status bar (akin to hyperlink targets in browsers): #68266
* allow dereferencing symlinks: #623580, #308437, #623124 (solved by the follow symlink extension[1], although afaik it only works for folders and not for files, for which it could open the containing folder and select the file), #622789 (rather about identifying that $PWD includes a symlink and jumping to the "physical" location)
* handle .desktop links similar to symlinks / use them as a fall back: #115805 (which i disaprove of), #607193, #358205 (does not mention desktop files itself, but solution offered in 607193), #614239 (which is quite special-case as only targetting the desktop, but valid -- having an icon on the desktop to open a frequently used directory is better handled with a .desktop file than with a symlink)
* offer follow/dont-follow options for recursive operations: #604572
* offer choice between absolute and relative symlinks: [rh154370]
* also mentioned in said reports; file operations should be aware of fs limitations before offering them

[1] http://p.outlyer.net/nautilus-follow-symlink/
[rh201855] https://bugzilla.redhat.com/show_bug.cgi?id=201855
[rh154370] https://bugzilla.redhat.com/show_bug.cgi?id=154370
Comment 1 Carlos Soriano 2016-11-21 09:49:09 UTC
Yeah, managing symlinks is kinda complex, and we have already lot of code for this managing. It's true it is missing really well handling, and all of those bugs happen :/
Comment 2 André Klapper 2021-06-18 15:48:21 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.