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 309196 - editing an image while a save or export is in progress can cause corruption
editing an image while a save or export is in progress can cause corruption
Product: GIMP
Classification: Other
Component: General
Other All
: High major
: Future
Assigned To: GIMP Bugs
: 387712 524885 597663 618321 774026 (view as bug list)
Depends on:
Reported: 2005-06-30 10:18 UTC by Sebastien Bacher
Modified: 2018-05-24 11:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Sebastien Bacher 2005-06-30 10:18:24 UTC
This bug has been opened here:

"Steps to reproduce:

1) Create a large image (screenshot as png is fine for older hardware)
2) Open the image in the gimp and modify it
3) Click the window close cross in the top right hand corner - a dialog should
pop up asking to save the changes
4) Click 'Save'
5) Quickly click the window close cross in the top right hand corner of the main
gimp window
6) Click 'Discard changes'
7) Image is corrupted if the Discard changes was clicked before the previous
save finished.

This is counter-intuitive - if I'm in the middle of a save, the close window
cross should bring up a dialog indicating a save is in progress - regardless
whether I click close on the image window or the main window."
Comment 1 Sven Neumann 2005-06-30 11:02:42 UTC
I am pretty sure we have a bug report on this for ages but I am unable to find
it at the moment.
Comment 2 Sven Neumann 2005-06-30 14:21:43 UTC
The culprit here is that we don't wait for the main loop to finish in
app_exit_after_callback(). This slows down exit and might cause gimp to hang if
plug-ins are still running. In the case of save plug-ins, this is probably
desired, with other plug-ins it could be quite annoying.
Comment 3 Ari Pollak 2005-10-03 13:20:45 UTC
This is also opened here:

The problem in that report is only slightly different - the user hasn't modified
the image, but wants to save it in a different format. So if the user closes the
main GIMP window while the save is still in progress, the dialog with the
Discard Changes window never comes up, and GIMP just quits immediately, only
partially saving the file.
Comment 4 weskaggs 2005-10-03 18:24:07 UTC
The bug report Sven is referring to in comment #1 is probably bug #145492, which
is certainly related although perhaps not quite a duplicate.
Comment 5 Daniel Holbach 2006-03-31 15:17:41 UTC
Could you from your experience tell, if this is related to ? Or should I forward the bug separately?
Comment 6 Michael Natterer 2006-05-06 21:49:30 UTC
That's a different problem that would be a duplicate of the
bug that asks for locking. Cant find this bug at the moment...
Comment 7 Sven Neumann 2006-12-20 15:36:11 UTC
*** Bug 387712 has been marked as a duplicate of this bug. ***
Comment 8 Luigi Maselli 2007-04-07 11:33:19 UTC
I can't believe that a so dangerous bug isn't fixed yet..
Isn't possible to lock/disable the painting area during saving?
Comment 9 Sven Neumann 2008-03-29 17:32:24 UTC
*** Bug 524885 has been marked as a duplicate of this bug. ***
Comment 10 Michael Schumacher 2009-10-09 12:28:09 UTC
*** Bug 597663 has been marked as a duplicate of this bug. ***
Comment 11 Sven Neumann 2009-10-09 13:34:29 UTC
We should really fix this and at least wait for save plug-ins to finish in the exit code.
Comment 12 Martin Nordholts 2010-05-11 05:33:06 UTC
*** Bug 618321 has been marked as a duplicate of this bug. ***
Comment 13 Martin Nordholts 2010-06-25 06:23:31 UTC
Me and mitch discusssed this a bit yesterday on IRC, let's move discussion on how to solve this here. Here's the current idea of a solution as I understand it:

1. Add a "locked" property to GimpImage. When an image is locked, it can't be modified.

2. Add PDB API to lock the image and make relevant plug-ins, in particular save plug-ins, lock the image while the image is being saved

3. In action updates, take GimpImage::"locked" into account and disable relevant actions, including "file-quit"

4. Make the GimpDisplayShell listen to this property and when set to TRUE, make the GimpCanvas insensitive (or something like that)

4. In gui.c, never exit until all images are non-locked

Mitch, is this in line with your idea for a solution as well?
Comment 14 Martin Nordholts 2010-06-25 07:20:40 UTC
Just realized that is not good enough, we must handle crashing plug-ins that has a lock.
Comment 15 Martin Nordholts 2010-06-27 12:16:24 UTC
We should be able to handle that in gimp_plug_in_cleanup_image() though.

If it sounds sane to at least one person more, I'll go ahead and make a patch.
Comment 16 Michael Natterer 2010-06-27 19:03:28 UTC
I just figured that while using/extending the existing locked concept
is the way to go, there are some subtle issues, let's discuss that
on IRC again.

Unrelated, why would the plug-in have to do the locking at all, that
can be done more safely by the file saving mechanism in the core
itself (unless I miss something here).
Comment 17 Martin Nordholts 2010-08-20 17:01:41 UTC
We won't have time to work on this for 2.8 if we want a release in 2010. Moving off milestone. We can put it back if someone magically starts giving us patches.
Comment 18 Martin Nordholts 2011-02-03 08:02:22 UTC
My current way to look at this problem is that this is an effect of a fundamental design problem. Plug-ins and the core run concurrently and use an API that is not designed for concurrent usage. We should either make our API safe for concurrent usage (hard) or we by design makes it impossible for plug-ins and the core to run at the same time (easier).

Won't have time to do that for 2.10 (3.0) though, putting on Future milestone...
Comment 19 Thomas Hotz 2013-06-16 16:27:25 UTC
Thank you for this information Martin. 

This bug is now on Launchpad
Comment 20 Michael Natterer 2016-11-08 11:22:03 UTC
*** Bug 774026 has been marked as a duplicate of this bug. ***
Comment 21 GNOME Infrastructure Team 2018-05-24 11:34:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: