Version: unspecified (using KDE 4.6.1) OS: Linux I have an external network server, running ftp with unicode support. When I create a network ftp folder with the contained wizard, I select unicode utf-8 for filenames, because I have many files with greek language filenames. When I open the created link, the connection works fine, except all the greek language filenames are shown with squares instead of the correct names. I tried filezilla and the greek filenames are shown fine. I tried the web interface of the server and the files are shown fine. I tried an ssh connection with the server and the files are shown fine. Is it right to assume that the multilanguage support in the ftp-link network folder wizard is broken? Both server and client pc, are unicode friendly in their settings. Reproducible: Always Steps to Reproduce: Create an ftp network folder with the wizard to an ftp server with multilanguage filenames. Actual Results: Wrong multilanguage filename display Expected Results: Correct multilanguage filenames
Nope. By default most kioslaves including kio_ftp use the default charset configured on your machine as the charset to display remote directories. Obviously, if the remote directory's charset is different that the one on your system, then you run into this issue. That is why applications like dolphin and konqueror give you the ability to manually change the remote charset. When you open the link you configured if it is opened using either dolphin or konqueror, you can change the encoding/charset to be used by selecting the appropriate encoding from the "Tools -> Select Remote Charset" menu.
As I said in the original post, I selected the utf-8 charset. The external nas has utf-8 filenames. I submitted this bug because it happens only in kio_ftp. As I said, If I use kio_fish and select utf-8 encoding all filenames are shown fine. So I conclude that kio_ftp and kio_fish are working differently with filename encodings.
(In reply to comment #2) > As I said in the original post, I selected the utf-8 charset. > The external nas has utf-8 filenames. > I submitted this bug because it happens only in kio_ftp. > As I said, If I use kio_fish and select utf-8 encoding all filenames are shown > fine. > So I conclude that kio_ftp and kio_fish are working differently with filename > encodings. Nope. They both use the same thing, namely the remoteEncoding() function from kdelibs/kio/kio/slavebase.h. If it does not work in one, then it should not work in the other one either. Do you have a test site where we can try to reproduce this ?
Nope. I have a local nas hard disk that I cannot give you access remotely. You are pretty sure that the behaviour is the same with fish:/ and ssh, so I will close the bug for now, until I have some new info.
I reopen this bug, because I could not find a solution for this . My nas server works find, with ssh(dolphin), filezilla (ftp), any software that I tested for ftp, with utf-8 support. The only program that destroys the names of files is dolphin. I updated my system characteristics.
I am willing to give you a limited access to my nas server, on a specific folder with greek encoded filenames to see that it behaves fine in ssh and not ftp in dolphin
I find there are other problems with beyond-ASCII characters in dolphin over fish. I have a file with the registered trademark symbol in the name (®). It appears correctly in dolphin over fish, however I cannot open in Dolphin, nor can I copy it from dolphin. It does not matter if I explicitly Select UTF-8 as the remote charset. Note that this worked fine with the version of Dolphin under plasma 4.
I don't know if this has been resolved, but I now have the following issues with two computers (one with Slackware64bit current + Frameworks 5.18.0 Plasma 5.5.3 Applications 15.12.1 dolphin-15.12.1) (and another with Arch linux 64 bit + Frameworks 5.17.0 Plasma 5.5.1 Applications 15.12.0 dolphin-15.12.0 The Slackware box is an upgrade from KDE4, and the ArchLinux box is a clean installation. The locale on both boxes is the same (bg_BG.UTF-8). The problem is in dolphin, when using kio-fish to copy files between the boxes. If the filenames are made of only ASCII characters they get copied OK, but files with filenames in cyrillic cannot be copied between those two computers. The error message says "files cannot be read, there is no such file", but dolphin shows the remote files and the encoding is correct (the filenames are readable). There is more to this. When connecting to those boxes from a computer with KDE4 installed and using kio-fish and dolphin, the files with cyrillic names get coppied OK. But the KDE5 computers cannot copy files with cyrillic names from the KDE4 computer. And one last thing: Connecting from the KDE4 computer to the KDE5 computer via tightvnc and openning a remote x11 session on the KDE5 computer (command is: xterm -geometry 80x24+10+10 -en bg_BG.UTF-8 -ls -title "$VNCDESKTOP Desktop" & twm &) - the session opens OK, but when one starts dolphin on command line in this twm session it cannot start and gives the following errors: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user' Trying to convert empty KLocalizedString to QString. QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-user' klauncher not running... launching kdeinit and then window for dolphin stays empty and dolphin never starts. Apart from the issues above KDE5 works well on both boxes mentioned above.
(In reply to Eric S from comment #7) > I find there are other problems with beyond-ASCII characters in dolphin over > fish. I have a file with the registered trademark symbol in the name (®). It > appears correctly in dolphin over fish, however I cannot open in Dolphin, > nor can I copy it from dolphin. It does not matter if I explicitly Select > UTF-8 as the remote charset. > > Note that this worked fine with the version of Dolphin under plasma 4. I have exactly same problem -- files with Czech characters (UTF-8 encoding) doesn't open in Dolphin 5.x over fish.
I'm going to open(In reply to Jan Dosoudil from comment #9) > (In reply to Eric S from comment #7) > > I find there are other problems with beyond-ASCII characters in dolphin over > > fish. I have a file with the registered trademark symbol in the name (®). It > > appears correctly in dolphin over fish, however I cannot open in Dolphin, > > nor can I copy it from dolphin. It does not matter if I explicitly Select > > UTF-8 as the remote charset. > > > > Note that this worked fine with the version of Dolphin under plasma 4. > > I have exactly same problem -- files with Czech characters (UTF-8 encoding) > doesn't open in Dolphin 5.x over fish. I'm going to open another issue for this. I'm guessing this is not being seen because it is v4.9.4 issue.
(In reply to Eric S from comment #10) > I'm going to open(In reply to Jan Dosoudil from comment #9) > > (In reply to Eric S from comment #7) > > > I find there are other problems with beyond-ASCII characters in dolphin over > > > fish. I have a file with the registered trademark symbol in the name (®). It > > > appears correctly in dolphin over fish, however I cannot open in Dolphin, > > > nor can I copy it from dolphin. It does not matter if I explicitly Select > > > UTF-8 as the remote charset. > > > > > > Note that this worked fine with the version of Dolphin under plasma 4. > > > > I have exactly same problem -- files with Czech characters (UTF-8 encoding) > > doesn't open in Dolphin 5.x over fish. > > I'm going to open another issue for this. I'm guessing this is not being > seen because it is v4.9.4 issue. Actually, there are no 5.x version offered for kio when reporting a bug here. WTF? Is the system just out of date or kio considered part of some other component now in Plasma 5? Also I'm not sure this issue (at least going by the title) is the right one for my and Jan Dosoudil's problem, that fish: cannot open, copy, rename, etc files with non-latin characters in their name. Searching in the bug system for characters under kio there are a whole host of problems with characters beyond ascii but the bugs all seem to be specific in ways that don't necessarily encompass this problem. So I still suspect we need to file another bug, but it's not entirely clear where.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!