Issues with IPv6 support and with global_opts structure

[Dave Dykstra]

I ran into two problems related to the IPv6 support recently added to
rsync.  I have only noticed these on Linux, I think because it alone of
my machine types supports the getaddrinfo() call; the rest use rsync's
builtin version of getaddrinfo().

The first problem is that on one Redhat 6.2 system I observed that when
rsync tries to create an IPv6 socket, the socket() system call is returning
an errno code of EINVAL.  The open_socket_in() function in rsync loops
through the different socket options that getaddrinfo() returned, but only
if socket() returns one of the error codes EPROTONOSUPPORT, EAFNOSUPPORT,
or EPFNOSUPPORT.  On that system it bombed and never went on try IPv4.
I went ahead and submitted a patch to CVS to also permit EINVAL.  Question
for IPv6 experts: why check the errno code at all?  Why not just loop
through any time socket() returns -1?

The second problem is that even if rsync is compiled with --disable-ipv6,
on Linux it still attempts to open an IPv6 socket.  This is because the
global_opts.af_hint variable is initialized to 0, when it should be
initialized to AF_INET to tell getaddrinfo() to prefer IPv4.  This brings
up a disadvantage with the new global_opts way of specifying global
variables; by default the whole structure is now initialized to zero and
there's no easy way to specify non-zero defaults unless you initialize all
the values positionally (I mean, the order has to match the structure order
in rsync.h) which I think is more error prone than just using global
variables.   I went ahead and submitted a patch to CVS to do it that way,
but I don't see any advantage to putting global options into a global_opts
structure and I recommend that we move back to global variables.

- Dave Dykstra