Clearing O_NONBLOCK from a pipe may lose data

[Corinna Vinschen]

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

-- 
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: <http://cygwin.com/pipermail/cygwin/attachments/20150223/70b6020b/attachment.sig>