Linux NFS development
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: CJ Kucera <pez@apocalyptech.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: NFS Causing issues with Gimp XCF files?
Date: Thu, 8 Nov 2007 17:02:34 -0500	[thread overview]
Message-ID: <20071108220234.GH1813@fieldses.org> (raw)
In-Reply-To: <20071108215404.GA8331@apocalyptech.com>

On Thu, Nov 08, 2007 at 03:54:04PM -0600, CJ Kucera wrote:
> I've been encountering a problem on my Linux machine running Gimp 2.4.1 [1]
> where XCF files that I save are occasionally corrupt, and can't be
> loaded again into the same program.  I'm 99% sure that this is something
> NFS-related, since this problem occurs only on my NFS shares, and never
> when I'm saving to my local hard drive.  I noticed this problem in Gimp
> 2.4.0 as well (it may have been happening in some of the 2.3 development
> versions as well, though I didn't notice).
> 
> Mostly right now I'd just like to find somebody other than me who can
> reproduce the problem.  I've put some files up at
> http://apocalyptech.com/media/gimp/ -
> 
>   * goinonboat.xcf - a Gimp file saved in an earlier version of Gimp
>   * goinonboat2.xcf - The same file, after I've saved to an NFS share
>   * dimension.png - The binary differences between the two files.
> 
> ... so if somebody has Gimp 2.4.0 or 2.4.1 available, would you mind
> loading up goinonboat.xcf, saving it to an NFS share, and then try to
> have Gimp re-open the image?
> 
> It's interesting (to me) to note that the differences are all in the
> width/height/bpp values writen by gimp's xcf_save_hierarchy() function
> from app/xcf/xcf-save.c.  [2] Instead of writing the correct
> width/height/bpp values, it ends up being zeros when the file is finally
> closed.  I've added in various debugging statements, and loaded up a
> debug build of gimp into gdb to trace through, and in all cases, the
> values being passed into the actual fwrite() calls are correct -
> something ends up writing them inappropriately in the end, though.
> 
> There *is* some fseek()ing going on during that part of the save
> process, and I've found that the situation improves (though not
> completely) when I start throwing in fflush() statements - so far, with
> liberal use of fflush() I've been able to make it so that only the
> "width" parameter ends up being zero.
> 
> Both the NFS server and my client machine (where I'm running gimp) are
> running vanilla 2.6.23.1 kernels, and nfs-utils 1.1.0.

Have you seen this?:

	http://bugzilla.kernel.org/show_bug.cgi?id=9315

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-11-08 22:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-08 21:54 NFS Causing issues with Gimp XCF files? CJ Kucera
2007-11-08 22:02 ` J. Bruce Fields [this message]
2007-11-08 22:07   ` CJ Kucera
2007-11-08 22:31     ` CJ Kucera
2007-11-08 22:43 ` Trond Myklebust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071108220234.GH1813@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=pez@apocalyptech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox