GNOME Bugzilla – Bug 323016
Add gnome_vfs_uri_resolve_symbolic_link API
Last modified: 2006-07-16 09:18:37 UTC
Steps to reproduce: 1. Create a symlink in your home directory as follows: cd ln -s "1234:5678" funnylink 2. Open your home directory in Nautilus, in either icon or list view. 3. Select the (broken) symbolic link "funnylink" by a single left click. 4. After a short pause, Nautilus "unexpectedly quits". Stack trace: Other information: A symbolic link containing a colon arises in the wild, because firefox and other mozilla browsers use such a symlink, called "lock", in the user's profile directory, to place a lock on the profile. The contents of this lock symlink is the text ${MACHINE_IP}:${FIREFOX_PID} -- e.g. "127.0.0.1:4567". So this crash can occur if a user tries to use Nautilus to delete the lock file. The crash does not occur if the symlink contains, for example, "1234" without the colon. The crash also does not occur if there really is a file ./"1234:5678" so that the link is no longer broken: create such a file with "touch" in the same directory as "funnylink", and repeat steps 2,3 above, and the crash does not occur.
Backtrace was generated from '/usr/bin/nautilus' (no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (no debugging symbols found) `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1225996608 (LWP 19504)] [New Thread -1236538448 (LWP 20781)] [New Thread -1236272208 (LWP 20780)] [New Thread -1234826320 (LWP 20779)] [New Thread -1233454160 (LWP 19506)] [New Thread -1227543632 (LWP 19505)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xffffe410 in __kernel_vsyscall ()
+ Trace 64392
Thread 1 (Thread -1225996608 (LWP 19504))
Confirmed with nautilus 2.12.1 on Ubuntu Breezy.
Another example might shed light. 1. If the broken symlink contains the text "file:///home/user/nosuchfile", then there is no crash. 2. If the broken symlink contains the text "fils:///home/usr/nosuchfile", then there is a crash. (Note, I changed "file" to "fils" here.) So perhaps, when the symlink does not contain the ordinary unix path of an existing file, Nautilus tries to interpret the character string as a URI if it looks plausible; and then crashes if the URI begins with something non-standard. Just guessing, though. I haven't looked at the source (don't feel able).
Yep, 100% reproducable. Reassigning to gnome-vfs. Backtrace was generated from '/opt/gnome-2.14/bin/nautilus' Using host libthread_db library "/lib/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208661536 (LWP 3902)] [New Thread -1210786896 (LWP 3903)] 0x00508402 in __kernel_vsyscall ()
+ Trace 64525
Looks like the recent change to use gnome_vfs_uri_append_string makes GnomeVFS interpret the contents of the appended string as URI, i.e. it tries to do URI chaining.
*** Bug 323791 has been marked as a duplicate of this bug. ***
I have just seen this as well. Gnome 2.12.3cvs there is a broken link that I selected in Nautilus. I wonder why it was shown in the first place. lrwxrwxrwx 1 nazgul nazgul 15 2005-05-26 16:37 st -> ST: Enterprise/ Then it crashed in gnome-vfs. After restart Nautilus does *not* display the broken link. So, it is most likely the colon in the name.
All gvfs based programs crashes with similar errorz(gtk file chooser...)
*** Bug 326352 has been marked as a duplicate of this bug. ***
I cannot reproduce this any more with latest 2.13cvs and 2.12.3 Teppo, Martin: can you confirm that as well?
Still crashes for me on HEAD.
Martin can you please tell the steps you performed to cause a crash?
1. ln -s "1234:5678" funnylink 2. click funnylink
Created attachment 59933 [details] [review] Proposed prelimitary patch gnome_vfs_uri_resolve_relative seems to interpret the ":" as a hint that this is an absolute URI. RFC 2396 claims that This "generic URI" syntax consists of a sequence of four main components: <scheme>://<authority><path>?<query> each of which, except <scheme>, may be absent from a particular URI. For example, some URI schemes do not allow an <authority> component, and others do not use a <query> component. So this seems to be wrong. I'm not sure how else we're meant to discover URIs, since our GnomeVFS URIs *always* have a scheme. Maybe we should also escape the culprit characters from the symlink name. The attached patch at least tries to abort when gnome_vfs_uri_resolve_relative returns NULL and return what we have up to this point. I'm not sure whether setting an error is the right thing to do, but when we have multiple subsequent resolution the returned URI might not be that bad after all.
I'm commiting Christians patch to avoid crashes in 2.14. However, I'm keeping this bug open because we're still doing the wrong thing here. We really shouldn't be using gnome_vfs_uri_resolve_relative, as its never right to treat the symlink value as a uri. Implementing a resolve_symlink() call should be very easy, but lets do that in the next cycle.
*** Bug 336684 has been marked as a duplicate of this bug. ***
Created attachment 68969 [details] [review] Proposed gnome_vfs_uri_resolve_symbolic_link implementation The attached patch adds public API for resolving symlinks and updates the docs accordingly.
Despite the missing Since: line it looks good to me.
Created attachment 68970 [details] [review] resolve_symbolic_link implementation proposal #2 This one also contains the "Since: 2.16" note in the docs and makes the private helper robust against NULL paths. Thanks to Christian Kellner for pointing this out.
Updating version.
Created attachment 68987 [details] [review] final resolve_symbolic_link implementation I've committed the attached patch which has slightly different semantics to the last one: The resolve_symlink helper expects non-NULL arguments (and asserts them), and we make sure that it isn't called with NULL.