Corrupted file

[Nick Hawkins]

Whilst saving a file I worked on the programme crashed and now won't re-open the file saying it is corrupt? Does anyone know how to rescue this situation - 20 hours work on file involved. Can attach file if necessary. Won't open in any other programme either.

[rich2005]

Very rarely is a corrupt Gimp .xcf recoverable, especially from Gimp 2.8 and WindowsXP.

Take precautions and save your work frequently with incremental names. Pays off in the long run.

[Ofnuts]

(02-23-2022, 11:25 AM)rich2005 Wrote: Very rarely is a corrupt Gimp .xcf recoverable,  especially from Gimp 2.8 and WindowsXP.

Take precautions and save your work frequently with incremental names. Pays off in the long run.

When I restarted Gimp 2.10 after a crash this morning, it offered to recover the files that were open...

[Fathom67]

(02-23-2022, 11:25 AM)rich2005 Wrote: Very rarely is a corrupt Gimp .xcf recoverable,  especially from Gimp 2.8 and WindowsXP.

Take precautions and save your work frequently with incremental names. Pays off in the long run.

GIMP can corrupt files as storage gets low. It seems to use storage as its scratch disk as RAM runs low, then once storage has zeroed out, it has nowhere to either save the file or update the file as you edit it. By the time it starts giving you "warnings", it's too late. In the worst cases, even when you figure out some way to save the file, it's too late to prevent it from being damaged, and already-saved files open in the program also get corrupted. I do save multiple files with incremental names, but that of course only eats up storage faster.

The point is that, sure, users can take all sorts of precautions, but applications shouldn't be corrupting any, let alone saved, files. So has this problem been reported?

[Ofnuts]

Gimp has a "tile cache". Fundamentally, all data could be on disk,  but to make things faster, some of this data (usually, all of it) is kept in RAM. How much RAM this can take is defined by the "Tile cache size" in the preferences. This sort of puts a cap on how much memory (real or virtual) Gimp will use. On modern system you can of course set a value much larger than your RAM, and Gimp will use your system swapping. If you set it to something more reasonable (like all your RAM minus 8GB) Gimp will do its own swapping (that can be more efficient than the system one, because Gimp knows what it needs to be in RAM, while the OS sapping heuristics could be far from optimal).

Gimp also assumes that the system is in good shape.  When Gimp starts swapping, the system is usually already under considerable strain and this is when software bugs and hardware problems show up. Gimp is very often not the culprit, but just an agent provocateur (Gimp is also very good at pointing at empty mouse batteries and worn out mouse button contacts).

You can of course report a bug with your damaged XCF as the smoking gun.