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 660567 - spurious warning on file save via chooser
spurious warning on file save via chooser
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.24.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2011-09-30 14:12 UTC by Allin Cottrell
Modified: 2013-05-22 19:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allin Cottrell 2011-09-30 14:12:51 UTC
In GTK 2.24.6, I construct a file-save dialog using
gtk_file_chooser_dialog_new() with an action of
GTK_FILE_CHOOSER_ACTION_SAVE. I type the name of a
file that does not yet exist and save. The action works
fine, but GTK throws a warning on this pattern:

(myprog:PID): Gtk-WARNING **: Unable to retrieve the 
file info for `file:///path/to/newfile': Error stating 
file '/path/to/newfile': No such file or directory

True, there's no such file or directory before the save,
but since we're in save mode there's no call to display
such a warning.
Comment 1 Paul Sorensen 2011-11-28 20:41:37 UTC
Confirmed also in version 3.2.0. I also confirmed the mode for the filechooser was set to GTK_FILE_CHOOSER_ACTION_SAVE.

The error is emitted when the Open button on the dialog. Not when gtk_file_chooser_get_filename() is called. So I suspect the bug is really in Gtk filechooser dialog not honoring the save mode rather than the underlaying filechooser.

Here is code for my browser button callback (almost straight from documentation example):

void tool_browse(GtkButton *button,gpointer user_data)
{
   gchar *filepath;
   GObject *object;

   GtkWidget *dialog = gtk_file_chooser_dialog_new("Select record file",
      GTK_WINDOW(gwcap->window_main),GTK_FILE_CHOOSER_ACTION_SAVE,
      GTK_STOCK_CANCEL,GTK_RESPONSE_CANCEL,
      GTK_STOCK_OPEN,GTK_RESPONSE_ACCEPT,
      NULL);
  gtk_file_chooser_set_do_overwrite_confirmation(GTK_FILE_CHOOSER(dialog),TRUE);

   if (gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT) {
printf("browse\n");
      filepath = gtk_file_chooser_get_filename(GTK_FILE_CHOOSER(dialog));
printf("filepath='%s'\n",filepath);
      object = gtk_builder_get_object(gwcap->builder,"entry_filepath");
      gtk_entry_set_text(GTK_ENTRY(object),filepath);
      g_free(filepath);
   }
   gtk_widget_destroy(dialog);
}
Comment 2 Timothy Arceri 2013-05-20 02:03:46 UTC
Hmm, could it have something to do with using GTK_STOCK_OPEN instead of GTK_STOCK_SAVE?

Maybe there is some code looking for GTK_STOCK_OPEN/"gtk-open" rather then GTK_FILE_CHOOSER_ACTION_OPEN in the filechooser somewhere.
Comment 3 Federico Mena Quintero 2013-05-22 19:37:55 UTC
If you just type /an/existing/directory/nonexistent-file.txt everything is normal with no warnings of any kind.

On the other hand, what happens right now in both gtk-2-24 and the master branch is that the file chooser puts up a dialog box telling you that /some/nonexistent/directory/filename.txt doesn't exist.  No warnings on the console, though.

I think this comes from the very end of name_entry_get_parent_info_cb().  I don't think the file chooser should return a filename in a nonexistent directory; the calling application may not be set up to handle nonexistent directories.

(If old versions of GTK+ printed a warning in the console, then that *was* a bug that has been fixed.)

So I'll close this bug.