rsync - Sep 2004 - rsync 2.6.2 with Posix socket on HP-UX

Hi,

I tried to compile rsync 2.6.2 as a 64-bit application
on HP-UX 11.23.

	$ CC=cc CFLAGS="-Ae +DD64" configure
	$ make
	$ make check

'make check' fails with daemon mode tests with the
following error message.

	rsync: socketpair_tcp failed (Address family not supported by protocol family).

There seems to be a problem with the mixture of BSD
and Posix socket specification.  So I modified
config.h so that define socklen_t as int32.

	#define socklen_t int32

This fixes the daemon mode problem.

I also tried to compile with Posix socket library.

	$ CC=cc CFLAGS="-Ae +DD64 -D_XOPEN_SOURCE_EXTENDED=1" \
	  LDFLAGS="-lxnet" configure
	$ make
	$ make check

'make check' also fails with daemon mode tests but with
the different error message.

	rsync: socketpair_tcp failed (Bad file number)

I check the source socket.c and found two problems.

Actual error occurs at the second connect() in
socketpair_tcp() (line 737) and the errno is EINPROGRESS.

	close(listener);
	if (connect_done == 0) {
>>>		if (connect(fd[1], (struct sockaddr *)&sock, sizeof sock) != 0
		    && errno != EISCONN)
			goto failed;
	}

	set_blocking(fd[1]);

Then it hits "goto failed" and there "listener" is closed
as it is not -1 and fails.  This overrides the errno to
EBADF.  I think -1 should be set to "listener" after the
close() to avid this problem.

The real problem is that "fd[1]" is non-blocking for the
second connect().  I think it can wait till the connection
is made and this fixes the problem that the second connect()
returns EINPROGRESS.  Simply moving "set_blocking(fd[1])"
before the connect() solves this problem.

Thank you,

Nobu Takahashi - HP Japan
nt@hpycla.kobe.hp.com

On Fri, Sep 03, 2004 at 03:40:33PM +0900, Nobu Takahashi
wrote:
> Then it hits "goto failed" and there "listener" is
closed as it is
> not -1 and fails.  This overrides the errno to EBADF.  I think -1
> should be set to "listener" after the close() to avoid this
problem.
Yes, that is a bug.  I've checked in your suggest fix.
> The real problem is that "fd[1]" is non-blocking for the second
> connect().  I think it can wait till the connection is made and this
> fixes the problem that the second connect() returns EINPROGRESS.
> Simply moving "set_blocking(fd[1])" before the connect() solves
this
> problem.
I hope that is a compatible fix for other systems.  I'm trying it out
on the rsync build farm and it will be in 2.6.3pre2 (coming out soon).

Thanks for the report!

..wayne..