Follow-up:
I can confirm that your example using rsync to fetch a remote tree also
fails on my system.
I built a work-around into cygwin1.dll that solves the first failure
cases in which socketpair() is involved on a system-wide basis, so
individual applications don't have to be patched. The pr
For the sake of completeness...
I wrote:
May you give some more details? For example, should I rebuild under
Cygwin-1.5 or 1.7? with cygport (but which uses rsync, sigh!)? which
patch to apply?...
I have rebuilt rsync-3.05 both on Cygwin-1.5 and 1.7 applying this patch:
--- util.c.orig 2008-
Karl (alias cygwin) wrote:
A way to find the answer would be to recompile your rsync without socketpair
support (as shown in my previous message)
and retry your test case.
May you give some more details? For example, should I rebuild under
Cygwin-1.5 or 1.7? with cygport (but which uses rsync
Corinna Vinschen wrote:
On Aug 14 00:07, Angelo Graziosi wrote:
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is the discussion in this thread related to
what I flagged here:
http://cygwin.com/ml/cygwin/2007-04/msg00143.
http://cygwin.com/acronyms/#TOFU
On Aug 14 00:44, cygwin wrote:
> Further tests with this little program show that the observed error only
> occurs when the socket is dup()'ed to STDIN (fd = 0), but not when
> dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup
> call
On Aug 14 00:07, Angelo Graziosi wrote:
> Christopher Faylor wrote:
>
>> "Socket operation on non-socket" sounds like the problem that
>
> I am just a little curious, is the discussion in this thread related to
> what I flagged here:
>
> http://cygwin.com/ml/cygwin/2007-04/msg00143.html
>
> and her
Further tests with this little program show that the observed error only
occurs when the socket is dup()'ed to STDIN (fd = 0), but not when
dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup
call with any positive integer (except 3 and 4).
Also, explicitly closing STDIN in a
I forgot to add that the same binary copy of the executable of the test
program (compiled under 1.7) works without error if I place the
cygwin1.dll version 1.5 into the same directory.
cygwin wrote:
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a fil
I wrote a small test program to isolate the problem from RSYNC.
The problem occurs when a file descriptor obtained from socketpair() is
dup2()'ed into STDIN and then closed. The close call fails.
Output from the program is as follows:
socket 1 = 3
socket 2 = 4
dup2 socket 1...
closing socket
A way to find the answer would be to recompile your rsync without
socketpair support (as shown in my previous message)
and retry your test case.
Angelo Graziosi wrote:
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is
Christopher Faylor wrote:
"Socket operation on non-socket" sounds like the problem that
I am just a little curious, is the discussion in this thread related to
what I flagged here:
http://cygwin.com/ml/cygwin/2007-04/msg00143.html
and here:
http://cygwin.com/ml/cygwin/2007-05/msg00677.html
After updating 2 other systems to cygwin 1.7, I find that they also work
fine in the same test.
However, that doesn't help much debugging this.
I found that the problem on the failing system is related to using Unix
domain sockets for the IPC pipes.
If I replace the socketpair() call in fd_p
Christopher Faylor cygwin.com> writes:
> >often this type of bug reappears, too - historical cygwin has had it in
> >the past with newlib's popen implementation (I fixed it 2006-08-22), as
>
> Just a point of order: Cygwin doesn't use the newlib version of
> popen.
It doesn't now, but did prior
On Thu, Aug 13, 2009 at 07:52:01PM +, Eric Blake wrote:
>cygwin sipxx.com> writes:
>
>>
>> - if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
>> - close(to_child_pipe[1]) < 0 ||
>> - close(from_child_pipe[0]) < 0 ||
>> - dup2(
cygwin sipxx.com> writes:
>
> - 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) {
> -
On Thu, Aug 13, 2009 at 08:30:53PM +0200, Corinna Vinschen wrote:
>On Aug 13 13:17, cygwin wrote:
>>The RSYNC application fails in close() on the pipe streams to and from
>>child processes created when rsync starts. When running rsync.exe and
>>cygwin1.dll from cygwin 1.5 within the 1.7 installati
On Aug 13 13:17, cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation
cygwin wrote:
> The RSYNC application fails in close() on the pipe streams to and from
> child processes created when rsync starts.
> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
> installation on the same system (WinXP pro),
> the identical invocation completes without err
The RSYNC application fails in close() on the pipe streams to and from
child processes created when rsync starts.
When running rsync.exe and cygwin1.dll from cygwin 1.5 within the 1.7
installation on the same system (WinXP pro),
the identical invocation completes without errors.
The problems ap
19 matches
Mail list logo
