Re: rsync + xp sp2 failing (solved!)

[Igor Pechtchanski]

Done.
Igor

On Fri, 10 Sep 2004, Corinna Vinschen wrote:

> Good catch, Brian!
>
> Could we give Brian another gold star, please?  That was the first I
> thought when reading this posting.
>
> Corinna
>
> > On Fri, 10 Sep 2004 01:19:34 -0700, Brian Dessent wrote
> > > Corinna Vinschen wrote:
> > >
> > > > All WSADuplicateSocket calls fail with 10045, "operation is not supported
> > > > for the type of object referenced", even thought the above created socket
> > > > handles are referenced.  That's weird.
> > > >
> > > > I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
> > > > that's a side effect of the new firewall in XP2.  Did you try with
> > > > switching off the firewall entirely?
> > >
> > > FWIW this error happens frequently enough for Apache under windows
> > > that it's in their FAQ:
> > > 
> > >
> > >  quote 
> > > Apache for Windows does not start. Error log contains this message:
> > > "[crit] (10045) The attempted operation is not supported for the
> > > type of object referenced: Parent: WSADuplicateSocket failed for
> > > socket ###". What does this mean?
> > > [...]

-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw

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

Re: rsync + xp sp2 failing (solved!)

[Corinna Vinschen]

Good catch, Brian!

Could we give Brian another gold star, please?  That was the first I thought
when reading this posting.


Corinna


On Sep 10 07:39, joellists wrote:
> Thanks all!
> 
> Turns out Aventail Connect was the problem (which was installed right around
> same time as SP2).  And here I was blaming it on Bill Gates ... shame on me
> :).  Anyway, uninstalling it solved the problem and I'm back in business.
> 
> Once again, thanks all for your time and ideas!
> 
> -- Joel
> 
> On Fri, 10 Sep 2004 01:19:34 -0700, Brian Dessent wrote
> > Corinna Vinschen wrote:
> > 
> > > All WSADuplicateSocket calls fail with 10045, "operation is not supported
> > > for the type of object referenced", even thought the above created socket
> > > handles are referenced.  That's weird.
> > > 
> > > I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
> > > that's a side effect of the new firewall in XP2.  Did you try with
> > > switching off the firewall entirely?
> > 
> > FWIW this error happens frequently enough for Apache under windows that
> > it's in their FAQ:
> > 
> > 
> >  quote 
> > Apache for Windows does not start. Error log contains this message:
> > "[crit] (10045) The attempted operation is not supported for the 
> > type of object referenced: Parent: WSADuplicateSocket failed for 
> > socket ###". What does this mean?
> > [...]

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: rsync + xp sp2 failing (solved!)

[joellists]

Thanks all!

Turns out Aventail Connect was the problem (which was installed right around
same time as SP2).  And here I was blaming it on Bill Gates ... shame on me
:).  Anyway, uninstalling it solved the problem and I'm back in business.

Once again, thanks all for your time and ideas!

-- Joel

On Fri, 10 Sep 2004 01:19:34 -0700, Brian Dessent wrote
> Corinna Vinschen wrote:
> 
> > All WSADuplicateSocket calls fail with 10045, "operation is not supported
> > for the type of object referenced", even thought the above created socket
> > handles are referenced.  That's weird.
> > 
> > I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
> > that's a side effect of the new firewall in XP2.  Did you try with
> > switching off the firewall entirely?
> 
> FWIW this error happens frequently enough for Apache under windows that
> it's in their FAQ:
> 
> 
>  quote 
> Apache for Windows does not start. Error log contains this message:
> "[crit] (10045) The attempted operation is not supported for the 
> type of object referenced: Parent: WSADuplicateSocket failed for 
> socket ###". What does this mean?
> 
> We have seen this problem when Apache is run on systems along with
> Virtual Private Networking clients like Aventail Connect. Aventail
> Connect is a Layered Service Provider (LSP) that inserts itself, as a
> "shim," between the Winsock 2 API and Window's native Winsock 2
> implementation. The Aventail Connect shim does not implement
> WSADuplicateSocket, which is the cause of the failure.
> 
> The shim is not unloaded when Aventail Connect is shut down. Once
> observed, the problem persists until the shim is either explicitly
> unloaded or the machine is rebooted. Another potential solution (not
> tested) is to add apache.exe to the Aventail "Connect Exclusion List".
> 
> Apache is affected in a similar way by any firewall program that 
> isn't correctly configured. Assure you exclude your Apache server ports
> (usually port 80) from the list of ports to block. Refer to your
> firewall program's documentation for the how-to.
>  end quote 
> 
> It's probably not directly related, but there is this blurb about LSP
> from the page on
>

> 
>  quote 
> Winsock self-healing
> 
> Detailed description
> 
> Winsock, Windows’ network socket facility for applications, is
> extensible by a mechanism known as a Layered Service Provider (LSP).
> Winsock LSPs are available for a wide range of useful purposes,
> including internet parental controls, and web content filtering. In
> previous versions of Windows XP, removing a malformed (also known as
> “buggy”) LSP could result in corruption of the Winsock catalog in the
> registry, potentially resulting in a loss of all network 
> connectivity. Winsock now has the ability to self-heal after a user 
> uninstalls such an LSP. 
>  end quote 
> 
> And finally, although it's probably not relevant, the following passage
> from
>

might help track down the problem:
> 
>  quote 
> IPv4 Inbound Connections for Applications. An application that completes
> a listen operation on a TCP socket or successfully binds to a UDP socket
> through Winsock is covered by this scenario. Examples of these
> applications include audio and video in MSN or Windows Messenger, or
> hosting a multiplayer game. For this scenario, ICF can automatically
> open and close ports as needed by the application. When an 
> application that needs to listen on a port or ports is being 
> installed by an administrator, it will need to ask the user if 
> he/she wants to allow the application to open ports in the firewall. 
> If the user consents to this, then the application should use the 
> INetFwV4AuthorizedApplication API to add itself to the 
> AuthorizedApplications collection as enabled. If the user does not 
> consent, then the application should use the 
> INetFwV4AuthorizedApplication API to add itself to the 
> AuthorizedApplications collection as disabled.
>  end quote 
> 
> Brian
> 
> --
> 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/





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

Re: rsync + xp sp2 failing

[Brian Dessent]

Brian Dessent wrote:

> However I doubt that rsync could possibly trigger this state, 
> so it's likely not relevant.  

...and, when it does apply you get an event id 4226 in the event logs,
which should be easy to verify as being absent in this case.

Brian

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

Re: rsync + xp sp2 failing

[Brian Dessent]

Chris Taylor wrote:

> Is it possible this is due to the changes in tcpip.sys and/or the tcp
> stack? I myself am using a hacked one without these changes, so I could
> test things to see if it is, if people can give me a specific set of
> things to do ;-)
> Unfortunately, half of the stuff in this thread went clean over my head,
> so I could easily be barking up the wrong tree

The change he's referring to is the limit in SP2 meant to catch worms
and malware that connect to random IP addresses.  MS's fix was to
throttle the TCP/IP stack when it reaches 10 outgoing half-open
connections.  Note: that's not 10 connections total, that's 10 half-open
connections, i.e. state SYN_SENT.  This only really happens when you try
to open a bunch of simultaneous connections to non-existant / dark IP
space, which is typical of a worm.  However I doubt that rsync could
possibly trigger this state, so it's likely not relevant.  Nor are the
changes regarding raw sockets.

Brian

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

Re: rsync + xp sp2 failing

[Chris Taylor]

On Fri, September 10, 2004 9:46 am, Corinna Vinschen said:
> On Sep 10 01:19, Brian Dessent wrote:
>
>> Corinna Vinschen wrote:
>>
>>
>>> All WSADuplicateSocket calls fail with 10045, "operation is not
>>> supported for the type of object referenced", even thought the above
>>> created socket handles are referenced.  That's weird.
>>>
>>> I'm still running XP SP1 and I can't reproduce this.  I'm wondering
>>> if that's a side effect of the new firewall in XP2.  Did you try with
>>> switching off the firewall entirely?
>>
>> FWIW this error happens frequently enough for Apache under windows that
>>  it's in their FAQ:
>> 
>>
>>
>>  quote 
>> Apache for Windows does not start. Error log contains this message:
>> "[crit] (10045) The attempted operation is not supported for the type of
>>  object referenced: Parent: WSADuplicateSocket failed for socket ###".
>> What does this mean?
>>
>
> Interesting.
>
>
>> And finally, although it's probably not relevant, the following passage
>>  from
>> > =/library/en-us/dnwxp/html/securityinxpsp2.asp>
>> might help track down the problem:
>>
>>  quote 
>> IPv4 Inbound Connections for Applications. An application that completes
>>  a listen operation on a TCP socket or successfully binds to a UDP
>> socket through Winsock is covered by this scenario. Examples of these
>> applications include audio and video in MSN or Windows Messenger, or
>> hosting a multiplayer game. For this scenario, ICF can automatically
>> open and close ports as needed by the application. When an application
>> that needs to listen on a port or ports is being installed by an
>> administrator, it will need to ask the user if he/she wants to allow
>> the application to open ports in the firewall. If the user consents to
>> this, then the application should use the INetFwV4AuthorizedApplication
>> API to
>> add itself to the AuthorizedApplications collection as enabled. If the
>> user does not consent, then the application should use the
>> INetFwV4AuthorizedApplication API to add itself to the
>> AuthorizedApplications collection as disabled.
>>  end quote 
>>
>
> I *pray* it's not related.
>
>
>
> Corinna
>
>

Is it possible this is due to the changes in tcpip.sys and/or the tcp
stack? I myself am using a hacked one without these changes, so I could
test things to see if it is, if people can give me a specific set of
things to do ;-)
Unfortunately, half of the stuff in this thread went clean over my head,
so I could easily be barking up the wrong tree

Chris

-- 
"And the Lord spake, saying, 'First shalt thou take out the Holy Pin. Then
shalt thou count to three, no more - no less. Three shall be the number
thou shalt count, and the number of the counting shall be three. Four
shalt thou not count, neither count thou two, excepting that thou then
proceed to three. Five is right out! Once the number three, being the
third number, be reached, then lobbest thou thy Holy Hand Grenade of
Antioch towards thy foe, who, being naughty in my sight, shall snuff it.'"



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

Re: rsync + xp sp2 failing

[Corinna Vinschen]

On Sep 10 01:19, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > All WSADuplicateSocket calls fail with 10045, "operation is not supported
> > for the type of object referenced", even thought the above created socket
> > handles are referenced.  That's weird.
> > 
> > I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
> > that's a side effect of the new firewall in XP2.  Did you try with
> > switching off the firewall entirely?
> 
> FWIW this error happens frequently enough for Apache under windows that
> it's in their FAQ:
> 
> 
>  quote 
> Apache for Windows does not start. Error log contains this message:
> "[crit] (10045) The attempted operation is not supported for the type of
> object referenced: Parent: WSADuplicateSocket failed for socket ###".
> What does this mean?

Interesting.

> And finally, although it's probably not relevant, the following passage
> from
> 
> might help track down the problem:
> 
>  quote 
> IPv4 Inbound Connections for Applications. An application that completes
> a listen operation on a TCP socket or successfully binds to a UDP socket
> through Winsock is covered by this scenario. Examples of these
> applications include audio and video in MSN or Windows Messenger, or
> hosting a multiplayer game. For this scenario, ICF can automatically
> open and close ports as needed by the application. When an application
> that needs to listen on a port or ports is being installed by an
> administrator, it will need to ask the user if he/she wants to allow the
> application to open ports in the firewall. If the user consents to this,
> then the application should use the INetFwV4AuthorizedApplication API to
> add itself to the AuthorizedApplications collection as enabled. If the
> user does not consent, then the application should use the
> INetFwV4AuthorizedApplication API to add itself to the
> AuthorizedApplications collection as disabled.
>  end quote 

I *pray* it's not related.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: rsync + xp sp2 failing

[Brian Dessent]

Corinna Vinschen wrote:

> All WSADuplicateSocket calls fail with 10045, "operation is not supported
> for the type of object referenced", even thought the above created socket
> handles are referenced.  That's weird.
> 
> I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
> that's a side effect of the new firewall in XP2.  Did you try with
> switching off the firewall entirely?

FWIW this error happens frequently enough for Apache under windows that
it's in their FAQ:


 quote 
Apache for Windows does not start. Error log contains this message:
"[crit] (10045) The attempted operation is not supported for the type of
object referenced: Parent: WSADuplicateSocket failed for socket ###".
What does this mean?

We have seen this problem when Apache is run on systems along with
Virtual Private Networking clients like Aventail Connect. Aventail
Connect is a Layered Service Provider (LSP) that inserts itself, as a
"shim," between the Winsock 2 API and Window's native Winsock 2
implementation. The Aventail Connect shim does not implement
WSADuplicateSocket, which is the cause of the failure.

The shim is not unloaded when Aventail Connect is shut down. Once
observed, the problem persists until the shim is either explicitly
unloaded or the machine is rebooted. Another potential solution (not
tested) is to add apache.exe to the Aventail "Connect Exclusion List".

Apache is affected in a similar way by any firewall program that isn't
correctly configured. Assure you exclude your Apache server ports
(usually port 80) from the list of ports to block. Refer to your
firewall program's documentation for the how-to.
 end quote 

It's probably not directly related, but there is this blurb about LSP
from the page on


 quote 
Winsock self-healing

Detailed description

Winsock, Windows’ network socket facility for applications, is
extensible by a mechanism known as a Layered Service Provider (LSP).
Winsock LSPs are available for a wide range of useful purposes,
including internet parental controls, and web content filtering. In
previous versions of Windows XP, removing a malformed (also known as
“buggy”) LSP could result in corruption of the Winsock catalog in the
registry, potentially resulting in a loss of all network connectivity.
Winsock now has the ability to self-heal after a user uninstalls such an
LSP. 
 end quote 

And finally, although it's probably not relevant, the following passage
from

might help track down the problem:

 quote 
IPv4 Inbound Connections for Applications. An application that completes
a listen operation on a TCP socket or successfully binds to a UDP socket
through Winsock is covered by this scenario. Examples of these
applications include audio and video in MSN or Windows Messenger, or
hosting a multiplayer game. For this scenario, ICF can automatically
open and close ports as needed by the application. When an application
that needs to listen on a port or ports is being installed by an
administrator, it will need to ask the user if he/she wants to allow the
application to open ports in the firewall. If the user consents to this,
then the application should use the INetFwV4AuthorizedApplication API to
add itself to the AuthorizedApplications collection as enabled. If the
user does not consent, then the application should use the
INetFwV4AuthorizedApplication API to add itself to the
AuthorizedApplications collection as disabled.
 end quote 

Brian

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

Re: rsync + xp sp2 failing

[Corinna Vinschen]

On Sep  9 21:00, joellists wrote:
> On Fri, 10 Sep 2004 00:09:29 +0200, Corinna Vinschen wrote
> > All WSADuplicateSocket calls fail with 10045, "operation is not supported
> > for the type of object referenced", even thought the above created socket
> > handles are referenced.  That's weird.
> > 
> > I'm still running XP SP1 and I can't reproduce this.  I'm wondering 
> > if that's a side effect of the new firewall in XP2.  Did you try 
> > with switching off the firewall entirely?
> 
> Yes, I did try turning off the service.  In fact, this has solved problems for
> other programs (Age of Kings, for instance) that absolutely won't work with
> the firewall enabled, even when you make what you think are the proper exceptions.
> 
> I find it hard to believe no one else is having this problem... anyway...
> 
> I'm guessing this may have something to do with it:
> 
> "A little more info on raw sockets and Windows XP SP2"
> http://blogs.msdn.com/michael_howard/archive/2004/08/12/213611.aspx

No, socketpairs don't use raw sockets.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: rsync + xp sp2 failing

[joellists]

On Fri, 10 Sep 2004 00:09:29 +0200, Corinna Vinschen wrote
> On Sep  9 17:21, Joel wrote:
> > Bob Byrnes wrote:
> > >If you can reproduce this using strace, the last hundred lines or so
> > >of the strace output might be enlightening.
> > 
> > Here's the strace output:
> 
> ...which is rather interesting.  As you already noticed, this doesn't
> happen before installing SP2.
> 
> First socketpair creation:
> 
> > 237736  384833 [main] rsync 2340 fdsock: reset socket inheritance since 
> > winsock2_active 1
> >   228  385061 [main] rsync 2340 build_fh_pc: fh 0x61781468
> >   142  385203 [main] rsync 2340 fhandler_base::set_flags: flags 
> > 0x10002, supplied_bin 0x0
> >   123  385326 [main] rsync 2340 fhandler_base::set_flags: 
> > O_TEXT/O_BINARY set in flags 0x1
> >   120  385446 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> > to binary
> >   123  385569 [main] rsync 2340 fdsock: fd 3, name '', soc 0x510
> >   154  385723 [main] rsync 2340 fdsock: reset socket inheritance since 
> > winsock2_active 1
> >   144  385867 [main] rsync 2340 build_fh_pc: fh 0x61781890
> >   127  385994 [main] rsync 2340 fhandler_base::set_flags: flags 
> > 0x10002, supplied_bin 0x0
> >   299  386293 [main] rsync 2340 fhandler_base::set_flags: 
> > O_TEXT/O_BINARY set in flags 0x1
> >   148  386441 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> > to binary
> >   119  386560 [main] rsync 2340 fdsock: fd 4, name '', soc 0x54C
> >   124  386684 [main] rsync 2340 socketpair: 0 = socketpair (...)
> 
> Looks good.
> 
> Second socketpair creation:
> 
> >  9505  399384 [main] rsync 2340 fdsock: reset socket inheritance since 
> > winsock2_active 1
> >   228  399612 [main] rsync 2340 build_fh_pc: fh 0x61781CB8
> >   310  399922 [main] rsync 2340 fhandler_base::set_flags: flags 
> > 0x10002, supplied_bin 0x0
> >   153  400075 [main] rsync 2340 fhandler_base::set_flags: 
> > O_TEXT/O_BINARY set in flags 0x1
> >   123  400198 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> > to binary
> >   120  400318 [main] rsync 2340 fdsock: fd 5, name '', soc 0x4D4
> >   150  400468 [main] rsync 2340 fdsock: reset socket inheritance since 
> > winsock2_active 1
> >   180  400648 [main] rsync 2340 build_fh_pc: fh 0x617820E0
> >   128  400776 [main] rsync 2340 fhandler_base::set_flags: flags 
> > 0x10002, supplied_bin 0x0
> >   114  400890 [main] rsync 2340 fhandler_base::set_flags: 
> > O_TEXT/O_BINARY set in flags 0x1
> >   115  401005 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> > to binary
> >   113  401118 [main] rsync 2340 fdsock: fd 6, name '', soc 0x508
> >   118  401236 [main] rsync 2340 socketpair: 0 = socketpair (...)
> 
> Looks good, too.
> 
> And now for something completely different, the first fork.  Socket handles
> are duplicated:
> 
> >  1031  420063 [main] rsync 2340 dtable::fixup_before_fork: fd 3 ()
> >   498  420561 [main] rsync 2340 
> > fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> > 0x510, win_proc_id 1684, prot_info_ptr 0x61781670
> >   279  420840 [main] rsync 2340 __set_winsock_errno: 
> > fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
> >   157  420997 [main] rsync 2340 dtable::fixup_before_fork: fd 4 ()
> >   176  421173 [main] rsync 2340 
> > fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> > 0x54C, win_proc_id 1684, prot_info_ptr 0x61781A98
> >   138  421311 [main] rsync 2340 __set_winsock_errno: 
> > fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
> >   122  421433 [main] rsync 2340 dtable::fixup_before_fork: fd 5 ()
> >   168  421601 [main] rsync 2340 
> > fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> > 0x4D4, win_proc_id 1684, prot_info_ptr 0x61781EC0
> >   141  421742 [main] rsync 2340 __set_winsock_errno: 
> > fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
> >   121  421863 [main] rsync 2340 dtable::fixup_before_fork: fd 6 ()
> >   169  422032 [main] rsync 2340 
> > fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> > 0x508, win_proc_id 1684, prot_info_ptr 0x617822E8
> >   138  422170 [main] rsync 2340 __set_winsock_errno: 
> > fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
> 
> All WSADuplicateSocket calls fail with 10045, "operation is not supported
> for the type of object referenced", even thought the above created socket
> handles are referenced.  That's weird.
> 
> I'm still running XP SP1 and I can't reproduce this.  I'm wondering 
> if that's a side effect of the new firewall in XP2.  Did you try 
> with switching off the firewall entirely?

Yes, I did try turning off the service.  In fact, this has solved problems for
other programs (Age of Kings, for instance) that absolutely won't work with
the firewall enabled, even when you make what you think are the proper exceptions.

I find it hard to believe no one else is having this problem... anyway...

I'm guessing this may have somethi

Re: rsync + xp sp2 failing

[Corinna Vinschen]

On Sep  9 17:21, Joel wrote:
> Bob Byrnes wrote:
> >If you can reproduce this using strace, the last hundred lines or so
> >of the strace output might be enlightening.
> 
> Here's the strace output:

...which is rather interesting.  As you already noticed, this doesn't
happen before installing SP2.

First socketpair creation:

> 237736  384833 [main] rsync 2340 fdsock: reset socket inheritance since 
> winsock2_active 1
>   228  385061 [main] rsync 2340 build_fh_pc: fh 0x61781468
>   142  385203 [main] rsync 2340 fhandler_base::set_flags: flags 
> 0x10002, supplied_bin 0x0
>   123  385326 [main] rsync 2340 fhandler_base::set_flags: 
> O_TEXT/O_BINARY set in flags 0x1
>   120  385446 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> to binary
>   123  385569 [main] rsync 2340 fdsock: fd 3, name '', soc 0x510
>   154  385723 [main] rsync 2340 fdsock: reset socket inheritance since 
> winsock2_active 1
>   144  385867 [main] rsync 2340 build_fh_pc: fh 0x61781890
>   127  385994 [main] rsync 2340 fhandler_base::set_flags: flags 
> 0x10002, supplied_bin 0x0
>   299  386293 [main] rsync 2340 fhandler_base::set_flags: 
> O_TEXT/O_BINARY set in flags 0x1
>   148  386441 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> to binary
>   119  386560 [main] rsync 2340 fdsock: fd 4, name '', soc 0x54C
>   124  386684 [main] rsync 2340 socketpair: 0 = socketpair (...)

Looks good.

Second socketpair creation:

>  9505  399384 [main] rsync 2340 fdsock: reset socket inheritance since 
> winsock2_active 1
>   228  399612 [main] rsync 2340 build_fh_pc: fh 0x61781CB8
>   310  399922 [main] rsync 2340 fhandler_base::set_flags: flags 
> 0x10002, supplied_bin 0x0
>   153  400075 [main] rsync 2340 fhandler_base::set_flags: 
> O_TEXT/O_BINARY set in flags 0x1
>   123  400198 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> to binary
>   120  400318 [main] rsync 2340 fdsock: fd 5, name '', soc 0x4D4
>   150  400468 [main] rsync 2340 fdsock: reset socket inheritance since 
> winsock2_active 1
>   180  400648 [main] rsync 2340 build_fh_pc: fh 0x617820E0
>   128  400776 [main] rsync 2340 fhandler_base::set_flags: flags 
> 0x10002, supplied_bin 0x0
>   114  400890 [main] rsync 2340 fhandler_base::set_flags: 
> O_TEXT/O_BINARY set in flags 0x1
>   115  401005 [main] rsync 2340 fhandler_base::set_flags: filemode set 
> to binary
>   113  401118 [main] rsync 2340 fdsock: fd 6, name '', soc 0x508
>   118  401236 [main] rsync 2340 socketpair: 0 = socketpair (...)

Looks good, too.

And now for something completely different, the first fork.  Socket handles
are duplicated:

>  1031  420063 [main] rsync 2340 dtable::fixup_before_fork: fd 3 ()
>   498  420561 [main] rsync 2340 
> fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> 0x510, win_proc_id 1684, prot_info_ptr 0x61781670
>   279  420840 [main] rsync 2340 __set_winsock_errno: 
> fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
>   157  420997 [main] rsync 2340 dtable::fixup_before_fork: fd 4 ()
>   176  421173 [main] rsync 2340 
> fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> 0x54C, win_proc_id 1684, prot_info_ptr 0x61781A98
>   138  421311 [main] rsync 2340 __set_winsock_errno: 
> fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
>   122  421433 [main] rsync 2340 dtable::fixup_before_fork: fd 5 ()
>   168  421601 [main] rsync 2340 
> fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> 0x4D4, win_proc_id 1684, prot_info_ptr 0x61781EC0
>   141  421742 [main] rsync 2340 __set_winsock_errno: 
> fixup_before_fork_exec:269 - winsock error 10045 -> errno 95
>   121  421863 [main] rsync 2340 dtable::fixup_before_fork: fd 6 ()
>   169  422032 [main] rsync 2340 
> fhandler_socket::fixup_before_fork_exec: WSADuplicateSocket error, sock 
> 0x508, win_proc_id 1684, prot_info_ptr 0x617822E8
>   138  422170 [main] rsync 2340 __set_winsock_errno: 
> fixup_before_fork_exec:269 - winsock error 10045 -> errno 95

All WSADuplicateSocket calls fail with 10045, "operation is not supported
for the type of object referenced", even thought the above created socket
handles are referenced.  That's weird.

I'm still running XP SP1 and I can't reproduce this.  I'm wondering if
that's a side effect of the new firewall in XP2.  Did you try with
switching off the firewall entirely?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  mailto:[EMAIL PROTECTED]
Red Hat, Inc.

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

Re: rsync + xp sp2 failing

[Bob Byrnes]

On Sep 9,  9:36am, [EMAIL PROTECTED] (Joel) wrote:
-- Subject: rsync + xp sp2 failing
>
> Failed to dup/close : Socket operation on non-socket
> rsync error: error in IPC code (code 14)@
> /home/lapo/package/tmp/rsync-2.6.2/pipe.c(73)
> 
-- End of excerpt from Joel

The rsync code in pipe.c looks like ...

if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
close(to_child_pipe[1]) < 0 ||
close(from_child_pipe[0]) < 0 ||
dup2(from_child_pipe[1], STDOUT_FILENO) < 0) {
rprintf(FERROR, "Failed to dup/close : %s\n",
strerror(errno));
exit_cleanup(RERR_IPC);
}

... so we need to determine why dup2 or close is failing.

The "pipes" are created earlier by fd_pair ...

int to_child_pipe[2];
int from_child_pipe[2];

...

if (fd_pair(to_child_pipe) < 0 || fd_pair(from_child_pipe) < 0) {
rprintf(FERROR, "pipe: %s\n", strerror(errno));
exit_cleanup(RERR_IPC);
}

... but they are in fact not pipes at all; they're actually socketpairs,
for platforms like Cygwin that support socketpairs:

/**
 * Create a file descriptor pair - like pipe() but use socketpair if
 * possible (because of blocking issues on pipes).
 *
 * Always set non-blocking.
 */
int fd_pair(int fd[2])
{
int ret;

#if HAVE_SOCKETPAIR
ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
#else
ret = pipe(fd);
#endif

if (ret == 0) {
set_nonblocking(fd[0]);
set_nonblocking(fd[1]);
}

return ret;
}

Cygwin always uses inet sockets to implement socketpairs, even
for AF_UNIX.  That partially explains "Socket operation on non-socket".

Has anything changed recently in the socketpair code?
This seems unrelated to my recent implementation of selectable pipes.

If you can reproduce this using strace, the last hundred lines or so
of the strace output might be enlightening.

--
Bob

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