User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060513 Ubuntu/dapper Firefox/1.5.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060513 Ubuntu/dapper Firefox/1.5.0.3 if thunar or gnome-volume-manager mount the volume instead of xfdesktop itself, then volume && is_mounted does not imply has VfsInfo. So info is null and leads to crash. So whether it's mounted or not make sure we get it mounted so we have an info attached. And only affects pmount-hal style dynamically created deleted mountpoint setups. Patch inlined since it's very small. This however depends on thunar's vfsmount allowing remount (bug #1833) or else it will not crash but pop up an error dialog. Index: src/xfdesktop-file-icon-manager.c =================================================================== --- src/xfdesktop-file-icon-manager.c (revision 21756) +++ src/xfdesktop-file-icon-manager.c (working copy) @@ -345,7 +345,7 @@ TRACE("entering"); - if(volume && !thunar_vfs_volume_is_mounted(volume)) { + if(volume) { GtkWidget *toplevel = gtk_widget_get_toplevel(GTK_WIDGET(fmanager->priv->icon_view)); GError *error = NULL; Reproducible: Always Steps to Reproduce: 1.start thunar and xfdesktop 2.plug in pmount-hal controlled media 3.click it in thunar 4.click its desktop icon
Hmm, I think to be safe we should always just check to see if info is NULL, and if it's a removable volume and is mounted, try to check the mountpoint again and get a non-NULL info. I'll play with this tonight when I get home.
right, that would make it independent of thunar mount's behaviour. Since crashes occur(ed) mostly on lack of info, if it could be NULL-ed on unmount there would not be a need for so many checks and corner case, just info or !info.
Ok, I'm pretty sure this should be fixed now (svn r21784). Reopen if not, as I haven't tested it.