This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.25-6: Win32 programs don't get correct >> redirection

On Dec 14 11:50, Corinna Vinschen wrote:
> On Dec 13 19:36, Eric Blake wrote:
> > 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
> > 
> > This issue was discussed on the lists in May:
> > 
> >
> > 
> > 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:
> [...]

Scratch that, I implemented the forth choice.  Eric's point

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

was right.  I implemented this now, for 1.5.25 as well as for the main
trunk.  I will look into implementing this in a more transparent way for
1.7.x, though.


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

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]