On Fri, Feb 23, 2018 at 10:38 AM, Nick Couchman <vn...@apache.org> wrote:

>
>> The UTF-16 equivalent for this in the byte order used by RDP would be:
>>
>>     43 6C 6F 75 53 74 6F 72 61 67 65 00
>>
>> Which is the equivalent of the string:
>>
>>     "ClouStorage"
>>
>> So you have apparently changed the UTF-16 string
>> ("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in
>> UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it
>> interprets it as such.
>>
>> - Mike
>>
>>
> Mike,
> I'm playing with configuring the drive name and looking at the FreeRDP
> source code, and I'm not sure that the actual name is supposed to be UTF-16
> encoded.
>
> If I use xfreerdp to connect to a system I can specify the following flag:
> /drive:tmp:/tmp
>
> When I connect to the system, I see a drive in the Computer called "tmp on
> linux-host" - which means it isn't passing through a drive letter, it's
> passing through a filesystem name.  What I suspect is happening is that
> this filesystem name is *not* supposed to be UTF-16 encoded and when you
> pass the UTF-16 encoded string that begins with either "G\0" (for
> "Guacamole", as is the default) or "C\0" (for "Cloud Storage", as Amarjeet
> is using), it takes the first character, stops at the null terminator, and
> then just uses that first character and calls it either "G on Guacamole
> RDP" or "C on Guacamole RDP" - which, because it's a single capital letter,
> makes it look like a drive letter, when it's actually technically a share
> name (\\tsclient\C or \\tsclient\G or \\tsclient\tmp).
>
>
FWIW - I took the \0 out of the GUACAMOLE_FILESYSTEM_NAME define (left one
at the end) and changed the length to match, compiled, and confirmed that
it works as expected - it shows "Guacamole on Guacamole_RDP" instead of "G
on Guacamole_RDP".

-Nick

Reply via email to