> > >> The spec does call for UTF-16, but you present an interesting and > plausible theory. If specifying non-UTF-16 does work, then one of the > following must be true: > > * UTF-16 should indeed be used, but not across the board in the case of > the drive, and we are erroneously using UTF-16 in some of the cases where > it is not allowed. > > So, was reading the spec, and there's definitely some degree of ambiguity about this. From the MS-RDPEFS spec [1]:
"...If the client supports DRIVE_CAPABILITY_VERSION_02 in the Drive Capability Set, then the full name MUST also be specified in the *DeviceData* field, as a null-terminated Unicode string <https://msdn.microsoft.com/en-us/library/cc241307.aspx#gt_b069acb4-e364-453e-ac83-42d469bb339e> . ..." If you click on the link to "Unicode string" [2], the following definition is provided: "*Unicode string*: A Unicode 8-bit string is an ordered sequence of 8-bit units, a Unicode 16-bit string is an ordered sequence of 16-bit code units, and a Unicode 32-bit string is an ordered sequence of 32-bit code units. In some cases, it could be acceptable not to terminate with a terminating null character. Unless otherwise specified, all Unicode strings <https://msdn.microsoft.com/en-us/library/cc241307.aspx#gt_b069acb4-e364-453e-ac83-42d469bb339e>follow the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." So, according to Microsoft's documentation, it could either be 8-bit, 16-bit, or 32-bit, and should be 16-bit if not specified, but maybe they forgot to specify?! Unfortunately none of their examples actually have any of that data filled in, so it's hard to know, and they themselves say it's one of the three. <Shrug> -Nick [1] - https://msdn.microsoft.com/en-us/library/cc241357.aspx [2] - https://msdn.microsoft.com/en-us/library/cc241307.aspx#gt_b069acb4-e364-453e-ac83-42d469bb339e
