GNOME Bugzilla – Bug 376687
GIMP seems to destroy .xcf files upon opening them
Last modified: 2008-01-15 13:14:58 UTC
Please describe the problem: Sometimes when I open an .xcf file with the gimp the file will be destroyed (sometimes partially, sometimes the whole file). Sometimes this happens very often, sometimes not at all (e.g. when I want to make a trace). Steps to reproduce: 1. I create an .xcf file with the gimp and save it. 2. Afterwards I create a backup of the file. 3. I close it and open it again. Sometimes I get the following message: XCF: This file is corrupt! I could not even salvage any partial image data from it. 4. I copy the backup over the original. 5. Opening it works. Actual results: Expected results: Does this happen every time? No. Other information: I have an 'original' file and a backup. The backup is one second younger than the original, yet the original is broken, while the backup still works. I can send the file to whoever wants to investigate. I'm also running gimp with strace, now, so that I can attach a trace here, as soon as I encounter the problem again.
If there is only one second between original and the backup - could it be that the backup is interfereing here? Did you ever compared all of the original files with their backups, regardless of whether you had opened them again or not?
This morning I managed to reproduce it. It definitely is a problem with the gimp. I checked the md5 sum of the file I opened before and afterwards. It changed from 29cf3a171615414c0db3d8bf88657020 to fad343554391a063e051a6b67f1eec4b I also have the strace output of the case when the file was destroyed (4.9M) and the strace output when trying again with the backuped file (38M). I also have the destroyed original file and the unbroken backup (both 190M), which fit the traces. Is there somewhere, where I can put this data (at least the traces)? For others to investigate?
You can attach traces to this bug report. But I don't think that we will investigate this. GIMP opens the file in read-only mode, so if that corrupts the file, then your operating system or your hardware is to blame.
The smallest trace is 4.9M, bugzilla does not allow me to attach them. I did intensive hardware stress tests (hard disk, memory). I won't swear that the OS (FreeBSD RELENG_6) is not at fault, but gimp is the only Software that causes trouble on the system. Here is a small grep over the trace: # grep -n stage4.xcf trace-original 88492:stat("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", {st_mode=0624, st_size=667297867660179424, ...}) = 0 88494:stat("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", {st_mode=0624, st_size=667297867660179424, ...}) = 0 88952:open("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", O_RDONLY) = 5 88956:access("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", F_OK) = 0 88957:stat("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", {st_mode=0, st_size=0, ...}) = 0 88958:access("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", R_OK) = 0 88985:open("/mnt/msdos/vault/graphics/space/starfield01/stage4.xcf", O_RDONLY) = 5 Does it mean anything that the 3rd stat call is different?
All the stat's look pretty bogus, I somehow doubt your file is 667297867660179424 bytes long too. However, you can clearly see GIMP is opening up the file with O_RDONLY (as Sven said), so it can't write to it anyway. It looks like your OS is at fault, perhaps the vfat driver is broken (assuming /mnt/msdos is vfat)