Bug 47729

initial patch :please note I didn't test it yet.. i'm doing it atm .

Okay, some mistakes spotted

> #ifdef G_OS_WIN32
>   struct sockaddr_in addr;
> #else
>   struct sockaddr_un addr;
> #endif

is followed by

>      new_fd = accept (g_io_channel_unix_get_fd (source),
>          (struct sockaddr *) &addr, &addrlen);

This code is wrong on Unix too - it always uses a sockaddr_un to store the peer address, even when the socket is actually a IPv4 or a IPv6 socket. But it's also wrong on Windows - it might use the IPv4 address struct to store a IPv6 address, which'll surely lead to corrupted stack because IPv6 addresses are significantly longer.

the addr variable is not actually read in the function after accept stores the address in it - and is not passed anywhere - so the easiest fix is to just remove the addr variable and pass NULL as the two latter arguments to accept().

Note that despite the name, g_io_channel_unix_get_fd is really the correct function to use even on Windows... From GLib docs:

"On Windows this function returns the file descriptor or socket of the GIOChannel."

However, this is not right:

> #ifdef G_OS_WIN32
>      channel = g_io_channel_win32_new_fd (new_fd);

new_fd is a socket, so you must use g_io_channel_win32_new_socket so the correct IO implementation in GLib is used (it really has to be different for sockets and files on Windows :()

Also, in get_socket_channel():

>   fd = g_socket_get_fd (sock);
>   io_channel = g_io_channel_unix_new (fd);

Here as well, instead of the unix_new() call we must use win32_new_socket() on windows.

*** Bug 47272 has been marked as a duplicate of this bug. ***

new patch with the changes

working patch, along with contact-manager/contact patch

OK - can be merged after the bug 47429 branch which this is based on is merged, provided you test file transfer again to verify the fixes for it are implemented correctly.

Merged, will be in 0.7.2. Thanks!