Windows: directory relative symlinks do not work

[ehuss]

When cloning a repository with symbolic links, the links will end up with forward slashes. These files cannot be read using typical APIs like CreateFileW (without FILE_FLAG_OPEN_REPARSE_POINT) which result in ERROR_INVALID_NAME. This assumes you have core.symlinks to true and have the necessary developer mode enabled.

Reproduction steps

1. Create a repository with a file symbolic link between directories. For example:
   • mkdir somedir
   • echo contents > somedir\foo
   • mklink foo somedir\foo
   • Init a repo, and add these two files
2. Have a libgit2 project which will clone the sample repo.
3. Notice that the resulting files have forward slashes, like this:
   10/01/2019 06:43 PM <SYMLINK> foo [somedir/foo]
   Also notice that these files cannot be opened using Windows apis (like in Notepad). Beware that msys tools (like cat) seem to be able to access them. I would guess that maybe they use FILE_FLAG_OPEN_REPARSE_POINT, read the link content, and translate the path manually.

Expected behavior

Should be able to open symlinked files on windows.

Actual behavior

Files fail to open.

Version of libgit2 (release number or SHA1)

08cfa43

Operating system(s) tested

Windows 10

[ethomson]

Should be able to open symlinked files on windows.

What does Git for Windows do here? What are the files that it creates?

I ask because it's not clear to me if both systems need to be fixed or if this is a limitation of libgit2 only.

[ehuss]

What does Git for Windows do here? What are the files that it creates?

It translates forward slashes to backslashes (source).

[ethomson]

It translates forward slashes to backslashes (source).

Thanks for validating this, that makes sense and we should match their behavior indeed.

[Idanlu]

Any news regarding this issue?

[pks-t]

Now there is: #5355. Thanks for your ping, @Idanlu!