Could not seek in XCF file

[nbeaudet]

Good day to all,

After applying many scripts to an image, I get the following message upon Saving an .xcf file:

Could not seek in XCF file

I am using Partha's 2.8.14 version, Windows 10 Pro 64 bit, Ram 16G.

When the file is ready for saving, it occupies around 7 G in current memory.

What is my problem?

TIA,

Nicolas Beaudet

[rich2005]

Welcome to gimp-forum.

That is a big image you are working on, but you do have plenty memory.

Maybe some more information required. Is that the regular Partha 2.8.14 or is it the portable version?

The message "Could not seek in XCF file" maybe scrambled in translation, could you post a screenshot or the original text.

Is this an existing .xcf image on disk that you are trying to over-write?
If it is, is it on a external or net-work drive?

Clutching at straws here when it comes to very large images.

[Ofnuts]

Is there enough space on disk? Unless there is an alway possible bug, this message would indicate that the file on disk is shorter than what the code expects. How big is the XCF supposed to be?

[nbeaudet]

(10-16-2016, 09:31 AM)rich2005 Wrote: Welcome to gimp-forum.

That is a big image you are working on, but you do have plenty memory.

Maybe some more information required. Is that the regular Partha 2.8.14 or is it the portable version?

The message "Could not seek in XCF file" maybe scrambled in translation, could you post a screenshot or the original text.

Is this an existing .xcf image on disk that you are trying to over-write?
If it is, is it on a external or net-work drive?

Clutching at straws here when it comes to very large images.

---

I am using Partha's regular 2.8.14.

Here is the original text: (FR)

L'enregistrement de « xxxxxxx\2016-09-20\DSC04617.xcf » a échoué :

Impossible de pointer dans le fichier XCF : Invalid argument

according to http://osdir.com/ml/commits.gnome/2016-09/msg08027.html , it is the supplied translation to Could not seek in XCF file

The error appears on first try to File/Save. The file is saved on an internal 3 TB drive.

---

(10-16-2016, 09:31 AM)Ofnuts Wrote: Is there enough space on disk? Unless there is an alway possible bug, this message would indicate that the file on disk is shorter than what the code expects. How big is the XCF supposed to be?

There is plenty of space on an internal 3 TB disk. On disk, my GIMP experience tells me that an XCF should be around 25 % of the amount indicated in Status Bar. For this file, I expect the xcf to be around (7 G x 25 %) : 1.75 G

[rich2005]

This is just a guess:

From your reference, the error concerns a function xcf-seek and I did find one bug report on that subject. Looks like it was fixed.

This is the start of the change log for 2.8.16

Changes in GIMP 2.8.16:
Core: Seek much less when writing XCF
Core: Don't seek past the end of the file when writing XCF
Core: Fix velocity parameter on .GIH brushes
Core: Fix brokenness while transforming certain sets of linked layers

Could be either or both first two, could be the fourth if using layers.

Regardless, it would be worth upgrading from Gimp 2.8.14 to the latest.

Other than that,
Big file coming in from a Nikon perhaps.
What format does it start as? Using a plugin to import a RAW file?
Lots of filters used. Have you tried saving a .xcf version after each filter application until it breaks?
Simplify the save path and file name, maybe C:\temp\01.xcf until you get it sorted.

[Ofnuts]

You are hitting a strange bug. There is only one place in the Gimp code where this message occurs, it is this very small function, that calls the fseek() system API.

Code:

gboolean
xcf_seek_pos (XcfInfo  *info,
             guint     pos,
             GError  **error)
{
 if (info->cp != pos)
   {
     info->cp = pos;
     if (fseek (info->fp, info->cp, SEEK_SET) == -1)
       {
         g_set_error (error, G_FILE_ERROR, g_file_error_from_errno (errno),
                      _("Could not seek in XCF file: %s"),
                      g_strerror (errno));

         return FALSE;
       }
   }

 return TRUE;
}

There are only two ways to make it return the "invalid argument" message:

• use an invalid seek type (but since SEEK_SET is hardcoded that can't be it)
  
• use a negative value...
  

There is some chance that the seek value held in a 32-bit number is seen as negative when it is bigger than 2GB. So maybe you file would actually be a bit bigger than 2GB and hit that possible problem. As a work around you can maybe save the file in two halves, the top half of layers and the bottom half (and later use File>Open to open the bottom layers and use File>Open as layers to add the top half.

If the cumulated sizes of the two files is bigger than 2GB, you have a good candidate for a bug report on http://bugzilla.gnome.org.

[nbeaudet]

Good day to all!

I have solved the problem by doing the following:

My scripts were creating 20+ layers and channels from Selections applied to the original image. Starting from a Sony .arw file, processed in RawTherapee, then imported into GIMP.

I have cut down the number of layers created from the script. GIMP's memory for the file is now around 5G, file on disk is now around 2G, safely stored on the internal drive.

Ofnut's technical explanation for the fseek in the API reminded me of .dbf limitations for the number of records stored. Limitations solved later by the .mdb Access files. This is remembrance of my GIS programming days.

Rich2005 suggestion of graduating to 2.8.18 runs into another set of issues for me. I will start another thread about these issues.

Thank you all,

Nicolas