Clearing O_NONBLOCK from a pipe may lose data

Corinna Vinschen
Mon Feb 23 14:03:00 GMT 2015

On Feb 23 11:56, Corinna Vinschen wrote:
> On Feb 22 22:07, Lasse Collin wrote:
> > Eric Blake wrote:
> > > On 02/20/2015 01:21 PM, Lasse Collin wrote:
> > > > The above Cygwin behavior would make it very easy to add a
> > > > workaround to xz for the pipe-data-loss problem: simply don't clear
> > > > O_NONBLOCK on stdout. However, I wonder if it is a bug in Cygwin
> > > > that the changes to file status flags aren't seen via other file
> > > > descriptors that refer to the same file description. If it is a
> > > > bug, then the workaround idea will cause trouble in the future when
> > > > the bug in Cygwin gets fixed.
> > > 
> > > Yeah, the fact that cygwin is buggy with respect to POSIX may break
> > > any workaround you add if cygwin is later patched.
> The problem is two-fold.  On one hand there's Windows not supporting
> some of the POSIX concepts.  So we can't rely on the OS to keep track
> of some essential information required to emulate POSIXy behaviour.
> So that's where Cygwin needs to keep track of the inforamtion.
> On the other hand there's the way Cygwin works.  Cygwin is just a DLL.
> It can propagate settings only from parent to child process, or it can
> keep shared memory around to share information between processes of the
> same user.  Most info, as the information stored for descriptors, is
> only propagated from parent to child.  We could switch to sharing via
> shared memory, but that opens up a vector for malicious programs.
> The only safe way around that [...etc...]

It just occured to me, another way to keep info around is what Cygwin's
advisory locking does:  What we could do is to revamp parts of the code
to use per-file description objects in a subdirectory in the native NT
"BaseNamedObjects" namespace.  That's something we could follow up on
when the new account handling stuff is stable enough.

> > Alternative idea: Would there be a significant downside if Cygwin
> > remembered if non-blocking mode was enabled at some point and close()
> > would use that flag instead of the current (non)blocking status to
> > determine if the background thread hack should be used?
> No, that should be doable with very minor effort.

That's still an option, of course.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <>

More information about the Cygwin mailing list