This part of the commit doesn't make sense to me...

Update: Ok, it does make a bit of sense. It's only a bit confusing.

It first calls CreateFileA without FILE_FLAG_OPEN_REPARSE_POINT.
That either returns a valid handle (to the target file) or return an invalid handle.
The invalid handle can mean three different things:

• there is no such file with that name
• there is a file with that name but it's a symlink and points to a non-existing file
• there is a file with that name but it's a unix socket

The code doesn't really check which case applies and (sort of) assumes it might be a symlink and calls S_follow_symlinks_to which calls readlink to follow the link (if it's a link I guess);
Eventually it calls CreateFileA again with the FILE_FLAG_OPEN_REPARSE_POINT flag set.

What I have/had initially in mind for this code was something like: (pseudo-code obviously):

    handle =
        CreateFileA(path, FILE_READ_ATTRIBUTES,
                    FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE,
                    NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT, NULL);
    if (handle != INVALID_HANDLE_VALUE) {
         result = GetFileInformationByHandleEx(handle, FileBasicInfo, &basicInfo, ...)
         if (baiscInfo.FileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {

              DeviceIoControl(handle, FSCTL_GET_REPARSE_POINT, ....)
              ....
              if (reparse_type == IO_REÄRSE_TAG_SYMLINK) {
                  handle =
                      CreateFileA(path, FILE_READ_ATTRIBUTES,
                             FILE_SHARE_DELETE | FILE_SHARE_READ | FILE_SHARE_WRITE,
                             NULL, OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL);

              }
         }
    }

That is: first open with FILE_FLAG_OPEN_REPARSE_POINT and if it's a symlink then call CreateFileA again but this time without the FILE_FLAG_OPEN_REPARSE_POINT flag so that it resolves the symlink.

An alternative to the current code could also be to change S_follow_symlinks_to to not follow the symlink chain and instead check the reparse_type.
That is:

• if CreateFileA(...., FILE_FLAG_BACKUP_SEMANTICS, ...) fails
• and if CreateFileA(...., FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINTS, ...) succeeds
• then check if reparse_type is 'symlink'. If it is return ENOENT

Thinking some more.. I guess that won't do the right thing if it's a symlink to a unix socket..
(I'll do some testing tomorrow)

I do the non-reparse-point open first because I expect it to be by far the more common case, and it does the right thing for win32_stat() for valid symlink chains.

I went direct for win32_readlink() mostly out of laziness - I didn't want to include the CreateFile/DeviceIOControl/WideCharToMultiByte() code here (though maybe a win32_readlink_handle() would help), and win32_readlink() does the job.

I don't really consider this code path to be performance critical.

And yes, a symlink chain to a socket fails the non-reparse CreateFile().

In what case was this needed?
When I test with a unix socket it seems GetFileType() returns FILE_TYPE_DISK.
Did you encounter a case in which it returned something else?

This part may be unnecessary, I ass-umed that it would fail, but didn't test.

Thanks for the review.