GNOME Bugzilla – Bug 114074
Symlinks to launched documents are not dereferenced
Last modified: 2005-07-11 10:33:40 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.
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.
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.
*** Bug 138814 has been marked as a duplicate of this bug. ***
*** Bug 147353 has been marked as a duplicate of this bug. ***
*** Bug 83435 has been marked as a duplicate of this bug. ***
*** Bug 48353 has been marked as a duplicate of this bug. ***
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).
sorry for the spam, this shouldn't be ASSIGNED.
again, sorry for the spam... looks like you can't get from ASSIGNED -> REOPENED in less than 2 steps.
Created attachment 46768 [details] [review] Proposed patch (against HEAD).
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.