Check symlink relative flag and use correct offsets on Windows

[Ziink4]

Hello,
Some symbolic links might incorrectly be reported as missing when Windows reports the pointed file as a relative path instead of absolute

The SymbolicLinkReparseBuffer structure has a special flag to indicate whether or not the result is relative or absolute.
I also switched from PrintNameOffset to SubstituteNameOffset because of this :

A symbolic link has a substitute name and a print name associated with it. The substitute name is a pathname (section 2.1.5) identifying the target of the symbolic link. The print name SHOULD be an informative pathname, suitable for display to a user, that also identifies the target of the symbolic link.

Reference : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/b41f1cbf-10df-4a47-98d4-1c52a833d913

[gulrak]

Looks like there is something wrong here, I guess one of the parameters should have been SubstituteNameLength on both changes, as it was before with PrintNameLength. That might be the reason all Windows pipelines fail with some tests with these changes.

[Ziink4]

You're right, what's intriguing to me is that on my Windows machine (running VS 2019), all the tests were passing just fine.

[gulrak]

I updated the master to do additional preparation of windows native paths that should help your PR. Can you try to incorporate it into your version to hopefully get the CI green? Tests fail on my Windows 10 with VS2019 too, not only CI.

[gulrak]

Thanks for the contribution, I checked the combination of my prefix handling and your PR together and tests looked good. Will be in the upcoming release this weekend.