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 409799 - gthumb destroys file when double-clicking in the "Save" dialog
gthumb destroys file when double-clicking in the "Save" dialog
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.9.x
Other All
: High critical
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
: 386436 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-02-19 23:05 UTC by stanis.trendelenburg
Modified: 2007-03-07 21:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description stanis.trendelenburg 2007-02-19 23:05:44 UTC
Please describe the problem:
When using a double click on the filename instead of selecting the file and then clicking the "Save" button in the "Save File" dialog, the file is destroyed (truncated to 0 bytes size).

Steps to reproduce:
1. Open an image file, and make changes (e.g. adjust brightness)
2. Click "Next". A popup asks whether to save changes. Click "Yes"
3. A file selection dialog appears. Double click on the original file name.
4. A popup asks whether to overwrite the file. Click "Yes"
5. The error message "Image type 'lain' is not supported" appears. Click "OK"

Actual results:
The file has been truncated to 0 bytes size

Expected results:
The file should have been saved

Does this happen every time?
Yes

Other information:
The type reported in the error message is not always 'lain'. At least one time, it was '-uri', another time it was 'text/plain'.

This bug happens in gthumb 2.7 and 2.9 on Fedora Core 6.
Comment 1 stanis.trendelenburg 2007-02-19 23:21:02 UTC
Correction:
This actually happens only when double clicking on the file name *twice*:

1. First, double click on the file name
2. Dialog pops up asking whether to overwrite (don't click anything)
3. Double click on the filename again (nothing happens)
4. Then, click 'OK' in the dialog from step 2.

The way I noticed this was when I was switching through the available windows while saving and the original popup ended up hidden under the "Save File" dialog so I did not notice it and double clicked on the filename again.
Comment 2 Michael Chudobiak 2007-02-20 12:51:32 UTC
Data loss confirmed in svn rev 1385.

- Mike
Comment 3 Michael Chudobiak 2007-02-20 13:58:55 UTC
The file selection widget shouldn't be active when the overwrite dialog is shown...

- Mike
Comment 4 Michael Chudobiak 2007-02-20 14:01:14 UTC
*** Bug 386436 has been marked as a duplicate of this bug. ***
Comment 5 Michael Chudobiak 2007-02-20 14:41:42 UTC
I think this is fixed in svn rev 1391. I made the file selection dialog the parent of the overwrite dialog.

Please test.

- Mike
Comment 6 Michael Chudobiak 2007-02-20 15:16:48 UTC
No, something is still wrong - the mime_type variable can still be corrupted somehow.

- Mike
Comment 7 Michael Chudobiak 2007-02-20 16:14:41 UTC
Something weird is happening in libgthumb/dlg-save-image.c:dlg_save_options. I added some printfs for debugging:

printf ("6a, %s\n\r",image_type);

        if (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_OK) {
                GtkWidget *widget; 
                int        ivalue, i = 0;

printf ("6c, %s\n\r",image_type);


and -sometimes- I'll get garbled output like this:

6a, jpeg
6c, jp\ufffd
               
Why is image_type being occasionally overwritten?

- Mike
Comment 8 Michael Chudobiak 2007-02-20 16:32:30 UTC
For the time being, I've patched in a fix where image_type is based on a copy of mime_type, rather than a pointer to a section of mime_type.

This fixes the problem, but doesn't explain why the mime_type corruption was happening to begin with.

Paolo or Manuel, can you see the source of corruption?

- Mike