X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Fri, 14 Dec 2007 11:50:05 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.5.25-6: Win32 programs don't get correct >> redirection
Message-ID: <20071214105005.GC25863@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4761DDA1 DOT 9050700 AT qualcomm DOT com> <4761EC47 DOT 3040803 AT byu DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4761EC47.3040803@byu.net>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 Dec 13 19:36, Eric Blake wrote:
> -----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 [...]

Even though it sounds nice to blame Windows, the blame is on Cygwin
entirely here.  The problem with O_APPEND mode is that you can switch
a file descriptor to and from append mode at will using fcntl.  This
functionality doesn't exist in the Win32 API.  You either open the
file handle in append mode or not, but you can't switch it back and 
forth.

For that reason, the file is always opened in generic write mode in
Cygwin.  Append mode is emulated in the write() call by seeking to
the end of the file before writing (in 1.5.x) or by using a feature
of the native NT ZwWriteFile call (in 1.7.x).

At this point we have three choices:

1. We revert to the old behaviour and accept a (long-standing) POSIX
   misbehaviour in terms of the file position in Cygwin child
   processes.

2. We keep the current behaviour and accept a (new) Win32 misbehaviour
   in terms of the file position in native Win32 child processes.

3. We (probably I) rework the append mode handling using a native
   NT feature to re-open a new handle from an existing handle while
   changing the append mode and keeping everything else as it is,
   thus risking that I break something else.

Solution 3 sounds like something which should only go into 1.7.x.  While
I usually tend to prefer correct POSIX behaviour over correct native
behaviour, it looks like a rather surprising change which might break a
lot of existing installations.  So it appears as if 1 would be the way
to go for now.  Oh well...


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/