resolve() doesn't resolve intermediate symlinks on MS-Windows

[idbrii]

:help resolve() says:

On MS-Windows, ...
When {filename} is a symbolic link or junction point, return
the full path to the target. ...

On Unix, repeat resolving symbolic links in all path
components of {filename} and return the simplified result.

resolve() should resolve all components of the path on MS-Windows like it does on Unix to make plugins more portable.

While not necessarily difficult to implement recursive resolve, it's cumbersome for every plugin to support that code.

Looks like dce1e89 (#3896) added the ability to resolve mklink-type links for files, but it doesn't work on folders within the path (but does work if the folder is the final component of the path).

Example failure:

set noshellslash
ec mkdir('c:\scratch\linktest-real')
! mklink /D c:\scratch\linktest-link c:\scratch\linktest-real
w c:\scratch\linktest-real\text.txt
ec resolve('c:\scratch\linktest-link\text.txt')
ec resolve('c:\scratch\linktest-link')

Expected:

c:\scratch\linktest-real\text.txt
c:\scratch\linktest-real

Actual:

c:\scratch\linktest-link\text.txt
c:\scratch\linktest-real

If I make link to text.txt instead, then resolve() also works as expected:

! mklink c:\scratch\linktest-real\text-link.txt c:\scratch\linktest-real\text.txt
ec resolve('c:\scratch\linktest-real\text-link.txt')

Expected and Actual:

c:\scratch\linktest-link\text.txt

Environment :

• Vim version: 8.1.1066 x64
• OS: Windows 10.0.17763
• GUI

[idbrii]

It looks like this can be achieved with GetFinalPathNameByHandle:

A final path is the path that is returned when a path is fully resolved. For example, for a symbolic link named "C:\tmp\mydir" that points to "D:\yourdir", the final path would be "D:\yourdir".

GetFinalPathNameByHandle is first available in Windows Vista, but symbolic links were also first available with Windows Vista.

[idbrii]

I mistakenly forgot /D when linking my directory which caused resolve to fail for links as the last component of a path. Links within the path still fail to resolve.

I updated the original issue text.

[k-takata]

Removing this check will fix the problem:

vim/src/os_mswin.c

Lines 1790 to 1794 in b58a4b9

	if ((GetFileAttributesW(p) & FILE_ATTRIBUTE_REPARSE_POINT) == 0)
	{
	vim_free(p);
	goto fail;
	}

However, I'm not sure this doesn't cause another issue.
What do you think @mattn?

[mattn]

I checkd with removing the part of code. Seems good to me.

[k-takata]

Looking at your PR #3896 again, the tests seem to fail without the check of the attribute:
https://ci.appveyor.com/project/chrisbra/vim/builds/22096039/job/8f27n0h9vee8n9oq

[k-takata]

Ah, the problem might be solved with the commit e17c269.
@mattn Have you checked whether the all tests pass with removing the part of code?

[zdm]

This issue is appears again in the last patches, after 1416.
Please, fix it.

[mattn]

This issue is tested on master branch.

vim/src/testdir/test_functions.vim

Lines 368 to 370 in 693f7dc

	call assert_equal('Xdir/text.txt', resolve('Xdir/text.txt'))
	call assert_equal(s:normalize_fname(getcwd() . '\Xdir\text.txt'), s:normalize_fname(resolve('Xdirlink\text.txt')))
	call assert_equal(s:normalize_fname(getcwd() . '\Xdir'), s:normalize_fname(resolve('Xdirlink')))

Maybe, your case is different from this.

[zdm]

"Signify" plugin stop worked again on windows after patch 1416, developers told me, that the problem is in reparse point or related.

[chrisbra]

@zdm Well, first thing would be trying to figure out an exact test case that fails for you. If I remember correctly you are not using reparse points, so I am wondering why you saw those failures. Please try to come up with a minimal reproducible test case and open a new ticket. Thanks.