https://bugs.winehq.org/show_bug.cgi?id=12401
--- Comment #60 from Indrek Ardel <eniw(a)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.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.