https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #60 from Indrek Ardel eniw@ardel.eu --- After decoding the base64 buffer in the log, you can see that the MountPointReparseBuffer.PathBuffer ends in a backslash and then a NULL terminator. Interestingly SubstituteNameLength and PrintNameLength differ by 2, with latter taking into account the trailing backslash, while the former doesn't. I don't know enough about the struct at the moment to say what's the intended purpose for either.
Since nt_target.Buffer received from get_reparse_target() is just pointed to the MountPointReparseBuffer.PathBuffer with the length taken from MountPointReparseBuffer.SubstituteNameLength, then copying length+1 WCHAR-s from it leads to copying the trailing backslash, not the NULL that was likely originally intended.
I cannot comment if nt_target.Length set by get_reparse_target() is the correct one. If it is, then this would necessitate a new string buffer allocation and copy, such that a NULL terminator could be set without polluting the original buffer. Which then later needs to be freed by the caller.
---
While searching for an utlity function to concatenate strings, I ended up finding RtlAppendUnicodeStringToString which does exactly what I had in mind, but seems like Rtl functions aren't either usable or widely used. So I concur that changing the current patch to add a null terminator of its own after copy is probably easier way to meet the desired standard for now.