GNOME Bugzilla – Bug 311187
GtkFileChooser creates ghost entries and thus plenty of applications misbehave
Last modified: 2005-07-27 18:05:24 UTC
I saw this happening with Gedit and Gimp and initially with Gedit I assumed this to be a different issue so I filed exactly this bugreport: http://bugzilla.gnome.org/show_bug.cgi?id=310554 But as I do believe this is mroe an internal issue with GtkFileChooser from GTK+ head. The issues with Gimp has been seen for many months now as well as many months the same issues with Gedit (which reasons I understood today). Is it possible for you people to have a look on above bugreport and/or move that report to become a GTK+ one ?
I can't reproduce it with today's GTK+ and Gedit. Which "ghost entries" do you mean? Note that I broke Save mode inadvertently on 2005/07/14, which is close to the date of your bug report (timezones?). I fixed it the next day. Could you please try with an updated GTK+ HEAD? What is the exact series of steps needed to reproduce this on your machine?
*** Bug 310554 has been marked as a duplicate of this bug. ***
Well my GNOME is from yesterday 20.07.2005 GTK+ HEAD, GNOME HEAD, GEDIT HEAD, GIMP HEAD and well whatever HEAD :) but this issue is there for months and only appears on strange occasions. Seems like it needs to get triggered somehow. What I mean by "ghost entries" are this: http://bugzilla.gnome.org/attachment.cgi?id=49538&action=view As you can see in the above attachment (please refer to the Gedit Bugreport) GtkFileChooser shows two entries of the same file. But only one file is saved in the directory. Checked up in console with MC and through ls. To exactly reproduce this all you need to do (at least here it's the case) is to run Gedit, type in some trash and then simply "save as" and press "save". No filename changes nothing and make sure to use "save as" (I haven't tested this with "save". Then press "save as" again once saved and do expand the dirlister. I always get two entries of "Unnamed Document 1" here. Of course when deleting them it's ok again. Also look here, and this is really hard to trigger: http://bugzilla.gnome.org/attachment.cgi?id=49542&action=view Files from my homedir once you work with Gimp for quite some time, that is going through different dirs, do some load/save operations there and here will then magically show you stuff like this. http://bugzilla.gnome.org/attachment.cgi?id=49541&action=view Never seen my "Desktop" dir and my "Screenshot*" files showing up under root. Of course these files and dir's aren't there but GtkFileChooser show them up there. That's strange, isn't it ? That's now the 4th time I get this behavior with Gimp (also with other files, this is just an enforced try to check this behavior). I got this some months ago the first time (half a year or so, dunno) then again one day (but restarting Gimp solved this) and now after I saw the same stuff to be valid with Gedit I clicked around like mad with Gimp's GtkFileChooser, copied, saved, loaded etc. over and over again between my homedir, tempdir and some other dirs and then it has occoured again, that stuff shown up magically on places where they shouldn't.. This will also make the GtkFileChooser become unusable, since it then doesn't allow saving, loading etc. anymore due to weird entries. You need to quit the application to get the behavior corrected again.
Woah, this happens after I get a bunch of warnings from the second "save as" dialog. Looks like a FolderVFS is getting corrupted; it has an invalid type identifier.
Steps to reproduce this: 1. open gedit 2. type something 3. File/Save as 4. hit Save (it will save to "Untitled Document 1") 5. type something else 6. File/Save as 7. hit Save you get a bunch of warnings then.
Confirmed! Yes, I think it's now time to forward this to the gnome-vfs people :) I also hope that this solves the Gimp issue. galaxy@ulixys:~ > gedit (gedit:3288): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkFileFolder' (gedit:3288): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkFileFolderGnomeVFS' (gedit:3288): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (gedit:3288): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (gedit:3288): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (gedit:3288): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gedit:3288): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (gedit:3288): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (gedit:3288): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (gedit:3288): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (gedit:3288): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject' (gedit:3288): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed galaxy@ulixys:~ >
*** Bug 300221 has been marked as a duplicate of this bug. ***
Bug #300221 identifies why this happens; it happens with filenames with spaces. Thanks a LOT to Sebastien for finding this bug for me :)
Indeed it happens with spaces. All the places in gtkfilesystemgnomevfs.c insert canonical and escaped URIs in the folder_vfs->children hash tables, except for the one in this trace:
+ Trace 61927
(note the unescaped "hola mundo" in the first frame) I'm trying to see why this happens.
Created attachment 49549 [details] [review] gedit-311187.diff This is actually a gedit bug. It's passing unescaped URIs to gtk_file_chooser_set_uri(), which causes the file chooser to end up with two entries in a hash table that should actually be one. This patch fixes this and simplifies the gedit code a bit.
Is the patch above okay to commit?
Federico: I and pbor have just finished to review this patch. I'm going to test and commit it just now.
Tested and committed. Thanks Federico. 2005-07-27 Federico Mena Quintero <federico@ximian.com> Fixes bug #311187: * gedit-file-selector-util.c (gedit_file_selector_save): Take a full URI instead of a basename for "default_filename"; actually, renamed this argument to "default_uri". (run_file_selector): Likewise. (create_gtk_selector): Likewise. Also, just call gtk_file_chooser_set_uri() with the default_uri if it is available. * gedit-file.c (gedit_file_save_as): Use the document's raw URI if we already have it and it is a file:/// URI --- don't split into dirname and basename.
OK, thanks for committing it :)