Problem with rsync 3.0.6-1 [and 3.0.5] under 1.7.0-62 and 63 [and 64]

Eliot Moss moss@cs.umass.edu
Fri Nov 13 12:31:00 GMT 2009


Corinna Vinschen wrote:
> On Nov 12 17:23, Eliot Moss wrote:
>>    41  320784 [main] a_test 5244 fhandler_socket::dup: here
>>    57  320841 [main] a_test 5244 fhandler_base::dup: in fhandler_base dup
>>    39  320880 [main] a_test 5244 fhandler_base::dup: dup() failed, handle 35C, Win32 error 6
>>    37  320917 [main] a_test 5244 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-64/winsup/cygwin/fhandler.cc:1151 windows error 6
>>    41  320958 [main] a_test 5244 geterrno_from_win_error: windows error 6 == errno 9
> 
> Duh!  Of course this is the actual error you see.  DuplicateHandle fails
> with ERROR_INVALID_HANDLE.  The same problem occurs in close(), but on
> the Winsock level where closesocket() returns with error 10038.
> Ultimately this means that every socket handle is not recognized as a
> handle at all in the child process for some unknown reason.
> 
> And why does that happen on some machines only, but not on others?  Is
> that a BLODA problem?  Did you seriously check all possible BLODAs?
> http://cygwin.com/acronyms/#BLODA
> http://cygwin.com/1.7/faq/faq.using.html#faq.using.bloda
> 
> I just searched for this problem via google and it turns out that Cygwin
> isn't the only software having this problem.  The second hit was already
> quite interesting:
> 
> http://www.vadvbbs.com/products/vadv32/support/index.php#What_does_Invalid_Socket_Handle_mean
> 
> Anyway, it would be nice if we could avoid this problem even if a BLODA
> is running.  There are three possible solutions which come to mind and
> which we can test.
> 
> May I send you an URL to an experimental Cygwin DLL via PM?

Sure.

I can also report that the first time I run a_test, a Windows popup happens
asking if I want to allow this program to access the network. I click
"Allow", but it seems not to be allowing.

I wrote a variant of a_test that, before it tries the dups, tries to have
the parent send something to the child, have the child read it, write
it back on the other pipe, and have the parent read it. Since it's
nonlocking I/O, I had to put in retry loops and used sleep(1) in them,
but on garden-flavor Unix it works. On cygwin on my box the parent
writes but the child never gets the data. It's as if Windows has
quarantined it, even though I said "Allow"!

Regards -- Eliot

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list