Check symlink relative flag and use correct offsets on Windows#74
Check symlink relative flag and use correct offsets on Windows#74gulrak merged 2 commits intogulrak:masterfrom Ziink4:master
Conversation
There was a problem hiding this comment.
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.
|
You're right, what's intriguing to me is that on my Windows machine (running VS 2019), all the tests were passing just fine. |
|
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. |
|
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. |
Hello,
Some symbolic links might incorrectly be reported as missing when Windows reports the pointed file as a relative path instead of absolute
The
SymbolicLinkReparseBufferstructure has a special flag to indicate whether or not theresultis relative or absolute.I also switched from
PrintNameOffsettoSubstituteNameOffsetbecause of this :Reference : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/b41f1cbf-10df-4a47-98d4-1c52a833d913