localdrives still use Python 2. Since Python 2 is getting old, dusty, and unsupported, we should port localdrives to Python 3.
I have contacted J. Bruce Fields <bfields@redhat.com> regarding the changes made to pynfs in r37154. Hopefully, these changes can be upstreamed.
I have tested the converted `tl-mount-localdrives` (r37154) on both Fedora 33 and SLES12 without noticing any issues. The following tests were performed: - Mounting a directory - Reading files from said directory - Writing files to said directory - Mounting multiple directories - Mounting a directory containing non-ASCII characters - Reading files from said directory (non-ASCII file name) - Writing files to said directory (non-ASCII file name)
Tested the following `tl-umount-localdrives` cases on SLES12 using Jenkins server build #2200: - [X] Mount names containing non-ascii characters and spaces - [X] On UTF-8 - [X] On Latin9 - [X] Unmounts current session - [X] Mounts removed from /proc/mounts - [X] /opt/thinlinc/sessions/<user>/<sessnum>/drives/ empty - [X] ~/thindrives/ symlink points to the previous session *with mounted drives*, or is removed if there are no previous sessions with mounted drives. - [X] Unmounts all sessions for user - [X] Mounts removed from /proc/mounts - [X] /opt/thinlinc/sessions/<user>/*/*/drives/ empty - [X] ~/thindrives/ symlink removed - [X] Unmounts all sessions for all users - [X] Mounts removed from /proc/mounts - [X] /opt/thinlinc/sessions/*/*/*/drives/ empty - [X] Verbose logging For testing multiple concurrent sessions with the same user the "Terminal" profile was used. Marking as resolved.
Found a corner case that is not currently covered. Tested with server build 2210. Scenario: 1. Client with locale UTF-8, server with locale Latin-1. 2. Name one of the exported folders with a character unavailable in the servers locale, e.g. 'fold€r'. 3. Log in with the client, and run ls ~/thindrives. Only folders with valid characters that are *before* the invalid foldername are shown (the order from TL client's Options->Local Devices). In 4.12.1, we were able to fetch folders with names that had unavailable characters, but the names were shown in the wrong encoding.
I tested server build 2210 on RHEL 8 and Ubuntu 20.04 with client version 4.12.1, and everything is working fine except for the corner case in comment 34. - [ ] Mount names containing non-ascii characters and spaces - [X] On UTF-8 - [ ] On Latin1 - [X] Mount multiple directories - [X] Read file from mounted directories - [X] Write file from mounted directories - [X] Can't write file to read-only mounted directories - [X] Unmounts current session - [X] Mounts removed from /proc/mounts - [X] /var/opt/thinlinc/sessions/<user>/<sessnum>/drives/ empty - [X] ~/thindrives/ symlink points to the previous session *with mounted drives*, or is removed if there are no previous sessions with mounted drives. - [X] Unmounts all sessions for user - [X] Mounts removed from /proc/mounts - [X] /var/opt/thinlinc/sessions/<user>/*/drives/ empty - [X] ~/thindrives/ symlink removed - [X] Unmounts all sessions for all users - [X] Mounts removed from /proc/mounts - [X] /var/opt/thinlinc/sessions/*/*/drives/ empty - [X] Verbose logging
The above mentioned issue has now been fixed. Marking as resolved.
With the move to python 3 there has been subtle changes to how the server-side mountpoints are named. This has to do with the fact that we do not know the client-side character encoding. Previously, we did not consider encodings and just considered the names as raw byte sequences. Let's consider the two incompatible character encodings UTF-8 and Latin-1. With this incompatible encoding pair we have four possible outcomes: 1. The client use UTF-8 (Windows and most Linux machines) and the server uses Latin-1. - All characters in the mountpoint name representable in Latin-1 gets correctly translated to the new encoding. Others get replaced by a '?'. 2. The client use Latin-1 and the server UTF-8. - All characters within the ASCII range in the mountpoint name are correctly translated to the new encoding. Others get replaced by the UTF-8 replacement character. 3. Both use UTF-8 (the most common scenario). - All characters are correctly translated. 4. Both use Latin-1. - All characters within the ASCII range are correctly translated. Others get replaced by '?'.
To clarify comment 40: Previously we did not consider encodings. Thus, we just assumed that the client and server both used the same encoding. For example, if we have a client running on a UTF-8 system and a server running on a Latin-1 system, the raw UTF-8 bytes from the client will be interpreted as raw Latin-1 bytes by the server, and thus any multibyte UTF-8 characters sent from the client will be interpreted as multiple Latin-1 characters by the server. In this case, a mounted directory called "ödeshög" on the client would get the name "thindrives/ödeshög", even though "ödeshög" is within the Latin-1 range.
Tested the following two scenarios with server build 2219, which both works well. > 1. The client use UTF-8 (Windows and most Linux machines) and the server uses > Latin-1. > - All characters in the mountpoint name representable in Latin-1 gets > correctly translated to the new encoding. Others get replaced by a '?'. Works as expected. > 2. The client use Latin-1 and the server UTF-8. > - All characters within the ASCII range in the mountpoint name are > correctly > translated to the new encoding. Others get replaced by the UTF-8 > replacement character. Works as expected.
I have tested the following scenarios and it works as expected: > 3. Both use UTF-8 (the most common scenario). > - All characters are correctly translated. Works as expected. > 4. Both use Latin-1. > - All characters within the ASCII range are correctly translated. Others > get > replaced by '?'. Works as expected. Now everything should be tested, so I will close this!
The changes applied to pynfs have now been upstreamed: http://git.linux-nfs.org/?p=bfields/pynfs.git;a=commit;h=e96aa245978208e9b0d8bdfe51bef3a879eb03cb
