From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4206 invoked by alias); 14 Dec 2007 02:34:19 -0000 Received: (qmail 4196 invoked by uid 22791); 14 Dec 2007 02:34:18 -0000 X-Spam-Check-By: sourceware.org Received: from qmta09.westchester.pa.mail.comcast.net (HELO QMTA09.westchester.pa.mail.comcast.net) (76.96.62.96) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Dec 2007 02:34:08 +0000 Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA09.westchester.pa.mail.comcast.net with comcast id QCxR1Y0050Fqzac591Pa00; Fri, 14 Dec 2007 02:34:06 +0000 Received: from [192.168.0.103] ([67.166.125.73]) by OMTA08.westchester.pa.mail.comcast.net with comcast id QSa41Y0081b8C2B3U00000; Fri, 14 Dec 2007 02:34:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=ZvVbSk3pO8IA:10 a=TSbVqHtbAAAA:8 a=xe8BsctaAAAA:8 a=gSFhVG1t8H_NgYEEP5AA:9 a=ZSzuJOkOj4FhdLH85xxm58nckiMA:4 a=eDFNAWYWrCwA:10 a=rPt6xJ-oxjAA:10 Message-ID: <4761EC47.3040803@byu.net> Date: Fri, 14 Dec 2007 02:34:00 -0000 From: Eric Blake User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: 1.5.25-6: Win32 programs don't get correct >> redirection References: <4761DDA1.9050700@qualcomm.com> In-Reply-To: <4761DDA1.9050700@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2007-12/txt/msg00334.txt.bz2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Jack Brennen on 12/13/2007 6:34 PM: > sh-3.2$ echo ABCDEFGHIJKLMNOPQRST > foo.txt > sh-3.2$ cmd /c echo UVWXYZ >> foo.txt > sh-3.2$ cat foo.txt > UVWXYZ > IJKLMNOPQRST This issue was discussed on the lists in May: http://thread.gmane.org/gmane.os.cygwin/89327/focus=89411 Cygwin 1.5.24 was incorrectly positioning fd's opened in append mode to the last byte just before exec'ing a child process, rather than leaving the position untouched (note that POSIX requires open(O_RDWR|O_APPEND)/lseek to always be at position 0, but fopen("a+")/ftell can be either 0 [as on Linux] or the end of the file [as on BSD] - cygwin currently uses the Linux approach). But it looks like this means that Windows programs are too stupid to realize that they are being handed a file opened in append mode, and blindly write to the current position, which happens to be the beginning of the file instead of the end. Maybe it is worth teaching cygwin's exec code that fd's in append mode must be repositioned to the end if the child about to be spawned is a non-cygwin program? But how reliable is cygwin's detection of whether the child is a cygwin process, so that we aren't violating POSIX by mistakenly repositioning the fd when the child is a cygwin process? Or do we make it even more complicated, by having the pre-exec code always reposition, but remember where it was beforehand, then cygwin children use that knowledge to position back to the correct location? - -- Don't work too hard, make some time for fun as well! Eric Blake ebb9@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYexH84KuGfSFAYARAnQ9AKDTupShtU7xMcku4I3k6AVBcn8S/ACfchqI r/mbrPmHdgxE7TuOpxuCnvA= =O+VW -----END PGP SIGNATURE----- -- 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/