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 639531 - No error is given when attempting to save to "nonexistent_subfolder/blah.txt"
No error is given when attempting to save to "nonexistent_subfolder/blah.txt"
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: Federico Mena Quintero
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2011-01-14 16:43 UTC by Chris Wilson
Modified: 2011-01-24 22:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chris Wilson 2011-01-14 16:43:17 UTC
When saving a file in seemingly any program, if you use an unacceptable character in the filename such as my/file.txt rather then getting a warning saying you cannot use / in a filename nothing at all happens, the file doesn't save and the user is given no explanation as to why. This might be confusing to some users who don't know they can't use that character and will just assume something is wrong.
Comment 1 Chris Wilson 2011-01-14 16:44:33 UTC
Originally reported at https://bugs.launchpad.net/gtk/+bug/615505
Comment 2 Federico Mena Quintero 2011-01-21 15:24:01 UTC
I'll change the summary of the bug for clarity.

The problem is not illegal characters.  When you type "my/file.txt", the idea is that you want to save to a file in the "my" subfolder.

However, when the "my" subfolder doesn't exist, this is what happens:

- gtk_file_chooser_default_should_respond() calls check_save_entry()

- check_save_entry() returns that everything is all right, and that my/file.txt is not a folder (it doesn't even exist)

- gtk_file_chooser_default_should_respond() goes into the "else" block after "if (is_folder)", and requests file info for my/file.txt with the async handler file_exists_get_info_cb().

- file_exists_get_info_cb() eventually runs and goes into the case for GTK_FILE_CHOOSER_ACTION_SAVE.  Since is_folder == FALSE, it goes on to check whether the parent folder exists.  "needs_file_type_check" is misnamed; it should be "needs_parent_folder_check".  The async handler for this check is name_entry_get_parent_info_cb(); it will get the result for the "my" subfolder.

- name_entry_get_parent_info_cb() runs.  It doesn't get an "info" because the "my" subfolder doesn't even exist, and so it goes into "This will display an error, which is what we want" and calls change_folder_and_display_error().

But in fact, the error is not displayed.  change_folder_and_display_error() calls gtk_file_chooser_default_update_current_folder() with the "my" subfolder.  Later, upon seeing that "my" doesn't exist, it switches to "my"'s parent folder - the folder in which we began.  No error gets presented.

I think the right solution is for name_entry_get_parent_info_cb() to present an error directly if the parent folder doesn't exist.  I'll try this and post a patch.
Comment 3 Federico Mena Quintero 2011-01-21 22:53:46 UTC
Fixed in commit a4a2d7618250407fa78cb5cd3184b7d20a11a7e8.
Comment 4 Chris Wilson 2011-01-22 01:38:11 UTC
Thanks a lot for the quick work :)
Comment 5 Chris Wilson 2011-01-24 10:50:10 UTC
From Launchpad bug tracker

"the bug seems to have been fixed in gtk trunk only, could you ask federico to commit to gtk-2-24 as well?"
Comment 6 Matthias Clasen 2011-01-24 15:13:51 UTC
Just a little note: direct communication is a winner...

Playing the intermediary here might be best intentions on your part, but is ultimatively highly annoying.
Comment 7 Federico Mena Quintero 2011-01-24 22:48:29 UTC
I didn't put this in 2.24 because there's a new string for an error message.

The commit cherry-picks cleanly to the 2.24 branch, though, so feel free to take it out and use it as a patch.