X-Spam-Check-By: sourceware.org Date: Mon, 23 Jul 2007 13:02:35 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: 1.5.24: data corruption problem with popen and gzip on a text mounted filesystem Message-ID: <20070723170235.GA17283@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <46A4BC14 DOT 1050603 AT merl DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, Jul 23, 2007 at 03:42:55PM +0000, Eric Blake wrote: >Hugh Secker-Walker merl.com> writes: > >> I'm having trouble getting correct behavior on a third-party OpenSource >> project that I'm building using Cygwin. The problem involves the >> writing of corrupt data to a file. The output file is created and >> written via popen("gzip > outputfile", "wb"). The data is fine if the >> filesystem is mounted in binary mode. The data is corrupted if the >> filesystem is mounted in text mode. >> >> My understanding of the documentation is that pipes and shells' stdin >> and stdout will be in binary mode if the CYGWIN env variable contains >> the 'binmode' setting, regardless of the binary/text mount flag of the >> filesystem the file is mounted on. > >Indeed - so you are handing the data to gzip in binary mode. And that's irrelevant wrt what goes on the disk anyway. gzip can compress a '\r\n' as well as a '\n'. >The problem, then, is likely not your program, but gzip - it seems to >me that gzip should be forcing binary mode but does not. cgf is the >cygwin gzip maintainer, so hopefully he can do something about this. >In the meantime, I'll probably fire off a mail to the bug-gzip list >with a patch (since the upstream maintainer for gzip also maintains >coreutils, so he is already familiar with text vs. binary issues in >other apps that he maintains). gzip is linked with binmode.o, like most of the things that I maintain (i.e., no upstream patch really necessary - isn't that my call?). If I use a really simple test case of just outputting directly to a text mode mount, it works fine. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/