> > 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). >> >> > 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: > > * The RDP server is detecting that we are (incorrectly) sending non-UTF-16 > and adjusting accordingly. Given the number of undocumented assumptions > I've encountered in the past while working with RDP (where the RDP server > will outright fail if some undocumented field is not set to a specific > value), this seems unlikely. > > * We are not setting some flag correctly, and the part of the > specification which requires UTF-16 for that field is not taking effect, > instead falling back to an older, non-Unicode version. > > * The RDP spec is wrong and UTF-16 is not used here. > > * 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. >
I think this is the most likely option - I'm wondering if the fact that it is presented as a sort of network filesystems, almost like a CIFS share, changes the way the RDP server expects that name to be presented. Clearly UTF-16 works for everything else, including printer name (in the changes I was making to allow that to be configured in GUACAMOLE-445, this definitely had to be UTF-16 encoded, else it would not render the name correctly), so my guess is that the filesystem name is just a one-off. This also matches with my quick audit of the FreeRDP source code - pretty much everything for redirection was run through the ConvertToUnicode() function, *except* the filesystem name. > > It is, however, *definitely* part of the spec. Accidental or not, Amarjeet > has effectively demonstrated through his changes that removing UTF-16 > entirely will cause problems. We need to tread very carefully here. > > Have you had a chance to look at the FreeRDP source code that I called out? As far as I can tell, xfreerdp, when passing through filesystems, does not encode the filesystem name in UTF-16, but I want a second set of eyes to verify that I'm seeing that correctly?? Beyond that, the only other possibility I can think of (outside of the options you've outlined above) is that we should be UTF-16 encoding it, but should using something other than a null terminator for the second byte? I have no idea if there's any validity to this idea, or if there's anything else you could possibly use besides the null terminator, so this option may be totally unreasonable. -Nick
