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 114074 - Symlinks to launched documents are not dereferenced
Symlinks to launched documents are not dereferenced
Status: RESOLVED NOTABUG
Product: nautilus
Classification: Core
Component: general
2.11.x
Other All
: High critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 48353 83435 138814 147353 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-31 03:16 UTC by Jeremy Nickurak
Modified: 2005-07-11 10:33 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Proposed patch (against HEAD). (1.13 KB, patch)
2005-05-22 21:06 UTC, Christian Neumair
none Details | Review

Description Jeremy Nickurak 2003-05-31 03:16:23 UTC
Package: nautilus
Severity: normal
Version: 2.2.3.1
Synopsis: Symlinks to launched documents are not dereferenced
Bugzilla-Product: nautilus
Bugzilla-Component: general

Description:
Description of Problem:
According to discussions from #gnome, nautilus is currently supposed to
dereference symlinks to documents if it attempts to load them in another
application. For example, symlinks to html documents should cause the
target document to be opened, allowing any relative url's to work.

Steps to reproduce the problem:
1. Create a file called test.html in ~/Documents
2. ln -s ~/Documents/test.html ~/test.html
3. Open the test.html symlink from ~ in nautilus.

Actual Results:
Web browser opens file:///<home>/test.html

Expected Results:
Web browser opens file:///<home>/Documents/test.html

How often does this happen?
Always.

Additional Information:
Because the URL to the document when opened as a symlink is in the wrong
directory, any relative urls in that file will fail to function.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-05-30 23:16 -------

Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.

Comment 1 Sebastien Bacher 2003-11-26 20:05:20 UTC
Seems to work as expected with nautilus 2.4, I'm closing this bug.
Feel free to reopen it if the bug is still here on your box.
Comment 2 Jeremy Nickurak 2003-11-27 02:29:15 UTC
Reopening, per results from nautilus 2.4.1

Note that this bug does not occur if you let nautilus open the HTML
file, since nautilus will dereference it itself. But if you open that
test.htlm symlink via "Open With: Galeon" (or another web browser) the
symlink, not the target, is passed to the application in question.
Comment 3 Zack Cerza 2004-08-11 16:50:36 UTC
*** Bug 138814 has been marked as a duplicate of this bug. ***
Comment 4 Zack Cerza 2004-08-11 16:51:09 UTC
*** Bug 147353 has been marked as a duplicate of this bug. ***
Comment 5 Zack Cerza 2004-08-11 16:52:33 UTC
*** Bug 83435 has been marked as a duplicate of this bug. ***
Comment 6 Zack Cerza 2004-08-11 16:53:50 UTC
*** Bug 48353 has been marked as a duplicate of this bug. ***
Comment 7 Zack Cerza 2004-08-11 16:57:57 UTC
This bug can cause data loss, as seen in Bug 147353. Bumping severity to
critical, priority to High (it's bad, but a rare situation).
Comment 8 Zack Cerza 2004-08-24 22:23:12 UTC
sorry for the spam, this shouldn't be ASSIGNED.
Comment 9 Zack Cerza 2004-08-24 22:24:00 UTC
again, sorry for the spam... looks like you can't get from ASSIGNED -> REOPENED
in less than 2 steps.
Comment 10 Christian Neumair 2005-05-22 21:06:53 UTC
Created attachment 46768 [details] [review]
Proposed patch (against HEAD).
Comment 11 Alexander Larsson 2005-07-11 10:33:40 UTC
I don't really agree with this. Why should we derefenrece the symlink? Its not
something that apps generally do. For instance bash does not when giving a
filename argument.

The html example case is pretty bogus. You might as well have the case where the
symlink of the html file is in the directory where the files it needs are, and
dereferencing the symlink in this case will break the html file.

This is quite similar to how nautilus handles symlinks to directories. There has
been much discussion and changes to this, but in the end we have decided to not
expand symlinks. If you really want a symlink that expands, you need to use a
desktop file shortcut.