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 705396 - Better IO error handling in gimp_imagefile_icon_callback()
Better IO error handling in gimp_imagefile_icon_callback()
Status: RESOLVED NOTABUG
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal trivial
: ---
Assigned To: Jehan
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-08-03 11:03 UTC by Jehan
Modified: 2013-08-04 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch for wider error handling. (830 bytes, patch)
2013-08-03 11:04 UTC, Jehan 		none Details | Review

Description Jehan 2013-08-03 11:03:10 UTC 
When querying image file info, there may be various kinds of IO errors.

In my "File > Open Recent" list, there was an image which did not exist anymore at this path. So I got the warning in terminal:

------------
gimp_imagefile_icon_callback: Error when getting information for file '/home/jehan/prog/poppy/Artworks/sample.xcf': No such file or
directory
------------

There is an error check in gimp_imagefile_icon_callback, so that it is useless to continue.

if (g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))

But it was not caught because it was not a G_IO_ERROR_CANCELLED, but a G_IO_ERROR_NOT_FOUND.
Basically we want to catch any IO error because they all mean that we won't get an icon anyway.
Small patch attached for this.
Comment 1 Jehan 2013-08-03 11:04:09 UTC 
Created attachment 250759 [details] [review]
Patch for wider error handling.
Comment 2 Michael Natterer 2013-08-04 11:18:29 UTC 
We only continue to set the proper states on the object, that bail
out is only for the case where the imagefile is finalized before
the callback ran, see dispose(). The warning is in #ifdef GIMP_UNSTABLE.

NOTABUG unless I missed something?
Comment 3 Jehan 2013-08-04 11:45:14 UTC 
Hmmm... no ok. Let's close as NOTABUG then.

I don't see any big problem with the current code anyway. It is simply that I hate seeing warnings for completely normal runtime environment (an image file being deleted/moved/renamed/whatever by the user being a totally usual thing), even when it is only in GIMP_UNSTABLE. What is GIMP_UNSTABLE for then, if not to catch these stuff during early development period?