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 519743 - Nautilus crashes on weird GFileInfos
Nautilus crashes on weird GFileInfos
Status: RESOLVED INCOMPLETE
Product: nautilus
Classification: Core
Component: general
2.23.x
Other Linux
: Normal critical
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 559548 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-01 14:38 UTC by Benjamin Otte (Company)
Modified: 2017-08-29 05:40 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
nautilus-filetype-symlink-fix.patch (496 bytes, patch)
2008-05-23 10:05 UTC, Tomas Bzatek
none Details | Review

Description Benjamin Otte (Company) 2008-03-01 14:38:33 UTC
(Sorry for being somewhat vague in the bug report, but I only just remembered it.)

While hacking on symlink support for gvfs-ftp, I noticed that Nautilus crashes when G_FILE_ATTRIBUTE_STANDARD_SYMLINK_TARGET is set on a GFileInfo, but G_FILE_ATTRIBUTE_STANDARD_IS_SYMLINK is not, I think it was asserting nautilus_file_is_symlink() and failing.

Either this is a bug in Nautilus, which shouldn't crash or in the GFileInfo documentation, which should tell you that specific attributes must only appear in pairs.
Comment 1 Tomas Bzatek 2008-05-23 10:05:51 UTC
Created attachment 111396 [details] [review]
nautilus-filetype-symlink-fix.patch

Additional check to accept not completely valid file info.

Another way would be to always check and set G_FILE_ATTRIBUTE_STANDARD_IS_SYMLINK flag when setting G_FILE_ATTRIBUTE_STANDARD_TYPE attribute with value G_FILE_TYPE_SYMBOLIC_LINK, however as long as we can set GFileInfo attributes directly, several tests on different places would be needed.
Comment 2 A. Walton 2008-05-27 23:23:16 UTC
The whole symlink handling code is a big strange in places, most particularly we're seeing crashes like the following in Ubuntu (currently private lp bug 227145, SSH backend related):

  • #0 g_str_hash
    from /usr/lib/libglib-2.0.so.0
  • #1 g_hash_table_lookup_extended
    from /usr/lib/libglib-2.0.so.0
  • #2 modify_link_hash_table
    at nautilus-file.c line 423
  • #3 update_info_internal
    at nautilus-file.c line 1838
  • #4 query_info_callback
    at nautilus-directory-async.c line 3431

This crash is especially bizarre considering the code path through update_info_internal to modify_link_hash_table to nautilus_file_get_symbolic_link_target_uri which finally causes us to crash.

There's an easy hack to avoid the crash here (return from the modify_link_hashtable call if we get a NULL from nautilus_file_get_symbolic_link_target_uri(), yet the nautilus_file_is_symbolic_link(file) returns TRUE, but this would be a really dirty hack considering the bad state was propagated this far into this section of the code. And we really need to throw in some better error checking through this entire path so that it will at least not crash and complain loudly on bad GFileInfos.
Comment 3 Cosimo Cecchi 2008-08-26 15:09:14 UTC
I guess this is still an issue.
Can we get that patch reviewed?
Comment 4 A. Walton 2008-11-06 08:49:17 UTC
*** Bug 559548 has been marked as a duplicate of this bug. ***
Comment 5 A. Walton 2008-11-06 08:52:30 UTC
Please note, the duplicate bug has a different structure coming from an older Nautilus, but presumably the same cause; somehow we're inserting a bad symlink into the hash table. Apparently this issue predates the GIO transition, though.
Comment 6 Marcus Carlson 2010-07-05 20:55:34 UTC
Would this be obsolete then?
Comment 7 Tobias Mueller 2010-09-18 16:38:50 UTC
Reopening as I don't see any open non-developer issue. I guess this is OBSOLETE though. So if a nautilus maintainer could jump in and comment on that, it'd be nice.
Comment 8 Cosimo Cecchi 2012-07-20 16:06:48 UTC
Mass component change due to BZ cleanup, sorry for the noise.
Comment 9 William Jon McCann 2012-08-26 16:13:13 UTC
What's the easiest way to reproduce this?
Comment 10 Benjamin Otte (Company) 2012-08-26 17:32:18 UTC
As this is a bug about the protocol spoken by gio, I suppose it requires writing or modifying source code to trigger.

You could for example remove the line that calls g_file_info_set_is_symlink() - say at http://git.gnome.org/browse/gvfs/tree/daemon/gvfsftpdircache.c#n667 and then use that.
Comment 11 Carlos Soriano 2016-03-01 17:52:17 UTC
I'm not sure this is  longer the case, can anyone reproduce?
Comment 12 Alexandre Franke 2017-08-29 05:40:32 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you are still able to reproduce.
Thanks!