I will share the observations: I have 2 identical usb drive. One ntfs, other fat32. On both I create a directory "Новая папка" (new folder) and "новый файл.txt" (new file.txt) We connect both and we watch contents after mount in the console of the thin client:
ls /media/ntfs_drive/ Новая Папка новый файл.txt System Volume Information
ls /media/fat32_drive/ :041d:043e:0432:0430:044f :043f:0430:043f:043a:0430 :043d:043e:0432:044b:0439 :0444:0430:0439:043b.txt System Volume Information
Later we go on the server. We open on the ntfs_drive server and we see normal Russian names of the file and a directory. It is possible to create new objects with the Russian names without problems. Checked even the Ukrainian alphabet. Everything is OK!
We open on the fat32_drive server. There is a directory": 041d: 043e: 0432:0430:044f: 043f: 0430:043f: 043a: 0430" and file": 043d: 043e: 0432:044b: 0439: 0444:0430:0439:043b.txt". It is impossible to create directories/files in Russian
sshfs transfers such names of files/directories with what them defined when mount...
To exclude randomness checked several times
-- С Уважением Строганов Роман
Am 21.01.19 um 15:14 schrieb Stroganov Roman:
I will share the observations: I have 2 identical usb drive. One ntfs, other fat32. On both I create a directory "Новая папка" (new folder) and "новый файл.txt" (new file.txt) We connect both and we watch contents after mount in the console of the thin client:
ls /media/ntfs_drive/ Новая Папка новый файл.txt System Volume Information
ls /media/fat32_drive/ :041d:043e:0432:0430:044f :043f:0430:043f:043a:0430 :043d:043e:0432:044b:0439 :0444:0430:0439:043b.txt System Volume Information
Later we go on the server. We open on the ntfs_drive server and we see normal Russian names of the file and a directory. It is possible to create new objects with the Russian names without problems. Checked even the Ukrainian alphabet. Everything is OK!
So NTFS-formatted drives work fine ...
We open on the fat32_drive server. There is a directory": 041d: 043e: 0432:0430:044f: 043f: 0430:043f: 043a: 0430" and file": 043d: 043e: 0432:044b: 0439: 0444:0430:0439:043b.txt". It is impossible to create directories/files in Russian
My guess is that FAT32 (to be more precise: the vfat mount module) doesn't support UTF-8 out of the box, and/or you're using some regional charset (KOI8-R, maybe?) instead of UTF-8. On a system that expects UTF-8, this will cause confusion ...
What happens when you umount the VFAT drive (leave it plugged in) as root, then mount it manually? Do the characters show up correctly now?
What happens when you use
mount -t vfat -o utf8 /dev/sda1 /media/fat32_drive
or
mount -t vfat -o utf8=0 /dev/sda1 /media/fat32_drive
or
mount -t vfat -o uni_xlate /dev/sda1 /media/fat32_drive
# (yes, that is uni_xlate, not unix_late)
Any change in the output?
Also, have a look at "man mount", look at the possible values for the options "codepage", and "iocharset", see if you can change one of them to make it work manually.
Do you have a regular Debian/Ubuntu Linux client where you can mount this FAT32 flash disk and everything works as expected?
If so, on that machine, please run "mount | grep fat" once the flash disk is mounted, and post the output.
If it just happens to be additional mount options, we could probably support them somehow.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Am 21.01.19 um 16:00 schrieb Stefan Baur:
My guess is that FAT32 (to be more precise: the vfat mount module) doesn't support UTF-8 out of the box, and/or you're using some regional charset (KOI8-R, maybe?) instead of UTF-8. On a system that expects UTF-8, this will cause confusion ...
Well, looking at the source of x2gousbmount, I think the problem is this:
if (system("mount -tntfs $dev /media/$name/$ldev -o uid=$user,sync,uni_xlate") == 0)
[...]
elsif (system("mount -tvfat $dev /media/$name/$ldev -o uid=$user,sync,uni_xlate") == 0)
[...]
So for both ntfs and vfat mounts, uni_xlate is set.
man mount says for ntfs:
uni_xlate={0|1|2}
For 0 (or no' or false'), do not use escape sequences for unknown
Unicode characters. For 1 (or yes' or true') or 2, use vfat-style
4-byte escape sequences starting with ":". Here 2 give a little-endian
encoding and 1 a byteswapped bigendian encoding.
while for vfat, the same parameter is documented to do something else: uni_xlate Translate unhandled Unicode characters to special escaped sequences. This lets you backup and restore filenames that are created with any Unicode characters. Without this option, a '?' is used when no translation is possible. The escape character is ':' because it is otherwise invalid on the vfat filesystem. The escape sequence that gets used, where u is the Unicode character, is: ':', (u & 0x3f), ((u>>6) & 0x3f), (u>>12).
AND man mount also says under "vfat"
utf8 UTF8 is the filesystem safe 8-bit encoding of Unicode that is used by the console. It can be enabled for the filesystem with this option or disabled with utf8=0, utf8=no or utf8=false. If 'uni_xlate' gets set, UTF8 gets disabled.
The last sentence is the important one.
So, since we are setting uni_xlate for the vfat mounts, utf8 gets disabled, which explains why you're seeing the hex codes instead.
A workaround for you is to cd into the ./patch/includes.chroot/usr/lib/x2go/tce/ directory you created, and edit the file x2gousbmount there.
Look for the line
elsif (system("mount -tvfat $dev /media/$name/$ldev -o uid=$user,sync,uni_xlate") == 0)
(all on one line)
and replace 'uni_xlate' with 'utf8'.
After that, create a new build and deploy it.
Please let us know if that worked. If it did, we will have to think about how to handle this in future releases.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
-
Stefan Baur -
Stroganov Roman