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
next prev parent 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