[WIP] Detect unix socket support at runtime

[rimrul]

I still need to teach t0301 to skip based on the runtime check and probably clean this up a little.

Once this PR is finished, this fixes #3892

[carenas]

it might be interesting to invent a third state for the Makefile variable that could be used to build it in an "dynamic/autodetect" mode.

I presume the default Windows build would rather have this hardcoded to avoid the extra delays, but as older versions of Windows become less common it might be worth switching to the "autodetect" mode and that way "mostly" enable this code.

[rimrul]

it might be interesting to invent a third state for the Makefile variable that could be used to build it in an "dynamic/autodetect" mode.

I have thought about that, but decided it wasn't all that necessary.

I presume the default Windows build would rather have this hardcoded to avoid the extra delays,

testing time git credential-cache exit (single core Windows 8.1 VM on an i5-4670 host) I get

real 0m0.064s
user 0m0.000s
sys 0m0.000s

with the hardcoded error message and

real 0m0.066s
user 0m0.000s
sys 0m0.000s

with the dynamicly detected error message, so I don't think we need to worry about the delays too much.

but as older versions of Windows become less common it might be worth switching to the "autodetect" mode and that way "mostly" enable this code.

Seeing as Cygwin 3.5 is supposed to be released in a few weeks, Git for Windows 2.44 is likely the last Version to support Windows 7 and Windows 8. That leaves only Windows 8.1 and some old non-updated Windows 10 versions.

[carenas]

That leaves only Windows 8.1

There is also that "opensource windows" that usually tracks windows server 2003, plus all the server versions that are also most likely to have longer lifetimes IMHO.

not sure if the "service" trick would work realiably in all of them for the detection code, and regardless, I presume that cygwin would rather need a different codepath since the UNIX socket implementation there predates the native version,

[rimrul]

That leaves only Windows 8.1

There is also that "opensource windows" that usually tracks windows server 2003,

I don't think Git for Windows ever supported reactOS. And I think upstream Git doesn't build there either.

Edit: It is seemingly possible to tweak Git for Windows 2.10.0 to work on ReactOS

plus all the server versions that are also most likely to have longer lifetimes IMHO.

As far as Microsoft is concerned they get the same 10 years as the desktop versions. As far as Git for Windows is concerned they go out whenever we drop support for their corresponding desktop version. So when I said Windows 8.1 I also meant Windows Server 2012 R2.

not sure if the "service" trick would work realiably in all of them for the detection code

It's more or less what Microsoft recommends, but I think I can set up some test VMs for that as well.

and regardless, I presume that cygwin would rather need a different codepath since the UNIX socket implementation there predates the native version,

AFAIK Cygwin Git (and MSYS2 Git) is already built without NO_UNIX_SOCKETS and shouldn't hit any codepath in compat/mingw.c those should use _can_use_unix_sockets() which is marked as inline and returns a constant 0 or 1 depending on wether NO_UNIX_SOCKETS is defined. Most compilers should optimize that out.

[rimrul]

not sure if the "service" trick would work realiably in all of them for the detection code

It's more or less what Microsoft recommends, but I think I can set up some test VMs for that as well.

I've tested this on Windows Server 2019 and 2012R2 and both behave like their desktop counterpart. I've also checked against the list of Nano Server APIs that all functions should be available in docker containers.

[hickford]

@rimrul Ever seen error "fatal: unable to connect to cache daemon: Unknown error"?

#5314

[rimrul]

I can't say that I have.
Maybe building with DEBUG_WSA_ERRNO defined could shine some light onto what's going on. I suspect a situation like described in this slightly outdated comment where strerror() doesn't know the errno produced by set_wsa_errno().

[rimrul]

I compiled a small test program:

#include <stdio.h>
#include <string.h>
#include <errno.h>

int main(void)
{
    printf("EINTR: %s\n", strerror(EINTR));
    printf("EBADF: %s\n", strerror(EBADF));
    printf("EACCES: %s\n", strerror(EACCES));
    printf("EFAULT: %s\n", strerror(EFAULT));
    printf("EINVAL: %s\n", strerror(EINVAL));
    printf("EMFILE: %s\n", strerror(EMFILE));
    printf("EWOULDBLOCK: %s\n", strerror(EWOULDBLOCK));
    printf("EINPROGRESS: %s\n", strerror(EINPROGRESS));
    printf("EALREADY: %s\n", strerror(EALREADY));
    printf("ENOTSOCK: %s\n", strerror(ENOTSOCK));
    printf("EDESTADDRREQ: %s\n", strerror(EDESTADDRREQ));
    printf("EMSGSIZE: %s\n", strerror(EMSGSIZE));
    printf("EPROTOTYPE: %s\n", strerror(EPROTOTYPE));
    printf("ENOPROTOOPT: %s\n", strerror(ENOPROTOOPT));
    printf("EPROTONOSUPPORT: %s\n", strerror(EPROTONOSUPPORT));
    printf("EOPNOTSUPP: %s\n", strerror(EOPNOTSUPP));
    printf("EAFNOSUPPORT: %s\n", strerror(EAFNOSUPPORT));
    printf("EADDRINUSE: %s\n", strerror(EADDRINUSE));
    printf("EADDRNOTAVAIL: %s\n", strerror(EADDRNOTAVAIL));
    printf("ENETDOWN: %s\n", strerror(ENETDOWN));
    printf("ENETUNREACH: %s\n", strerror(ENETUNREACH));
    printf("ENETRESET: %s\n", strerror(ENETRESET));
    printf("ECONNABORTED: %s\n", strerror(ECONNABORTED));
    printf("ECONNRESET: %s\n", strerror(ECONNRESET));
    printf("ENOBUFS: %s\n", strerror(ENOBUFS));
    printf("EISCONN: %s\n", strerror(EISCONN));
    printf("ENOTCONN: %s\n", strerror(ENOTCONN));
    printf("ETIMEDOUT: %s\n", strerror(ETIMEDOUT));
    printf("ECONNREFUSED: %s\n", strerror(ECONNREFUSED));
    printf("ELOOP: %s\n", strerror(ELOOP));
    printf("ENAMETOOLONG: %s\n", strerror(ENAMETOOLONG));
    printf("EHOSTUNREACH: %s\n", strerror(EHOSTUNREACH));
    printf("ENOTEMPTY: %s\n", strerror(ENOTEMPTY));
    printf("EIO: %s\n", strerror(EIO));
    return 0;
}

This is the output:

EINTR: Interrupted function call
EBADF: Bad file descriptor
EACCES: Permission denied
EFAULT: Bad address
EINVAL: Invalid argument
EMFILE: Too many open files
EWOULDBLOCK: Unknown error
EINPROGRESS: Unknown error
EALREADY: Unknown error
ENOTSOCK: Unknown error
EDESTADDRREQ: Unknown error
EMSGSIZE: Unknown error
EPROTOTYPE: Unknown error
ENOPROTOOPT: Unknown error
EPROTONOSUPPORT: Unknown error
EOPNOTSUPP: Unknown error
EAFNOSUPPORT: Unknown error
EADDRINUSE: Unknown error
EADDRNOTAVAIL: Unknown error
ENETDOWN: Unknown error
ENETUNREACH: Unknown error
ENETRESET: Unknown error
ECONNABORTED: Unknown error
ECONNRESET: Unknown error
ENOBUFS: Unknown error
EISCONN: Unknown error
ENOTCONN: Unknown error
ETIMEDOUT: Unknown error
ECONNREFUSED: Unknown error
ELOOP: Unknown error
ENAMETOOLONG: Filename too long
EHOSTUNREACH: Unknown error
ENOTEMPTY: Directory not empty
EIO: Input/output error

Unfortunately that narrows down the list of errors it could be less than I would have liked.