One more INFO I would like to share which is as follows :-
*Link target of that folder* : home/gk/.rdp_drive/CLOUD { gk is username
}
On Sat, Mar 3, 2018 at 6:52 PM, Amarjeet Singh <amarjee...@gmail.com> wrote:
> I have seen one more folder with the name *Cloud Storage on 127.0.0.1*
> which is not accessible.
>
> Link to view the screenshot :- https://www.dropbox.com/s/
>> t2emg56wxg0nito/linux_folders.PNG?dl=0
>
>
>
> Below is the error I got while opening the folder :- Refer the screenshot
>
>>
>> Link to view the screenshot : https://www.dropbox.com/s/
>> w11d1hj81gwazvs/error_linux.png?dl=0
>
>
>
> I have no idea about it.
>
> Regards,
> Amarjeet Singh
>
>
>
>
>
> On Sat, Mar 3, 2018 at 6:42 PM, Amarjeet Singh <amarjee...@gmail.com>
> wrote:
>
>> Thanks Nick,
>>
>>
>> Below is the link to view the screenshot :-
>>
>> Windows : https://www.dropbox.com/s/97m3x94vewi4q2j/windows_device_
>> redirection.PNG?dl=0
>>
>> Linux : https://www.dropbox.com/s/x7mego94nduosbz/liux_device_redi
>> rection.PNG?dl=0
>>
>>>
>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>
>>
>>
>> I will fix it.
>>
>>
>>> On XRDP on Linux, you will not see this, as XRDP does not look at
>>> either the client name, nor the the filesystem name for presenting this
>>> share.
>>
>>
>> I am seeing the same . Please view the screenshots.
>>
>>
>> Regards,
>> Amarjeet Singh
>>
>>
>> On Sat, Mar 3, 2018 at 6:31 PM, Nick Couchman <vn...@apache.org> wrote:
>>
>>> On Sat, Mar 3, 2018 at 7:09 AM, Amarjeet Singh <amarjee...@gmail.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> I have done the following changes to fix the above issue which works
>>>> both in *Windows *as well as *Linux RDP.*
>>>>
>>>>
>>>>>
>>>>> *#define GUAC_FILESYSTEM_NAME "C\0L\0O\0U\0D\0\0\0"**#define
>>>>> GUAC_FILESYSTEM_NAME_LENGTH 12*
>>>>
>>>>
>>>>
>>>> *Instead of using above configurations I have used the following (
>>>> No UTF-16 encoding is required ) :- *
>>>>
>>>>
>>>>> *#define GUAC_FILESYSTEM_NAME "CLOUD"**#define
>>>>> GUAC_FILESYSTEM_NAME_LENGTH 5*
>>>>
>>>>
>>>>
>>>>
>>> While the string apparently does not need to be UTF-16 encoded, it does
>>> need to be null-terminated, which you're missing, here.
>>>
>>>
>>>> *and I have used UTF-16 encoding in the following :-*
>>>>
>>>>
>>>> * guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage"); *
>>>>
>>>> *to *
>>>>
>>>> #define GUAC_DRIVE_NAME "C\0l\0o\0u\0d\0
>>>> \0S\0t\0o\0r\0a\0g\0e\0\0\0"
>>>> #define GUAC_DRIVE_NAME_LENGTH 28
>>>>
>>>> and used the above in the *guac_rdpdr_send_client_name_request
>>>> function .*
>>>>
>>>
>>> Note that the drive name and client name are *not* the same thing. The
>>> client name is used for redirection, but is used in a broader sense to
>>> identify the client connecting to the server. I don't know off the top of
>>> my head what the encoding should be for that, but probably UTF-16.
>>>
>>> Your screenshots did not come through, but the storage should show up as
>>> <Filesystem Name> on <Client Name>, so, in your case, you should see
>>> "Cloud" on "Cloud Storage" on Windows. On XRDP on Linux, you will not see
>>> this, as XRDP does not look at either the client name, nor the the
>>> filesystem name for presenting this share. Instead, there's a value
>>> determine on the XRDP side, either in the code or in a configuration file,
>>> for the name of the share, and then it uses the PreferredDosName setting
>>> for the folder name. None of the changes you have done (nor the ones I
>>> have done in the pull request for the JIRA issue) will impact the way XRDP
>>> sees it, and this is not because of Guacamole, this is because of how the
>>> XRDP code handles it.
>>>
>>> -Nick
>>>
>>
>>
>
