| Summary: | Cannot open remote files with "special characters" (non-ASCII) in path from konqueror/dolphin | ||
|---|---|---|---|
| Product: | [Unmaintained] kio | Reporter: | Marcos David <marcosgdavid> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | adawit, andresbajotierra, asenlekoff, christopher.m.braeuer, finex, lorefice2, pei, richard.e.morton, wonko |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Unspecified | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Marcos David
2009-09-08 17:07:43 UTC
Cannot reproduce using trunk: I've renamed a .odt file from: "myfilename.odt" to: "ç ã á é õ.odt" After I've clicked on it from Dolphin. The file was correctly opened by OO.org. Oops forgot to mention it was a remote SMB folder. And the special char are in a directory name example: smb://server/directório/file.odt BTW, in Tools menu, you have an option to manually select the charset when browsing remote filesystems; this could be useful to workaround the issue. Thanks Hi, yes I know about that option. But that has issues to. I filled another about it some time ago (https://bugs.kde.org/show_bug.cgi?id=188653) Changing the remote charset had no effect. I have this issue as well. I am trying to copy two folders of music from a smbfs share mounted on my system /var/lib/mythtv/music/ one folder is called Jose Gonzalez and the other is the similar with the accented e's. Dolphin copies and allows you to rename one, but not the other. strangely we have the same issue in the terminal also. The Dolphin error is: The file or folder /var/lib/mythtv/music/Jos� Gonz�lez does not exist. where the e's are represented with little diamond shame symbols with ? in the middle of them. This is also how they are displayed in the file pane and in bash. Running Kubuntu Karmic, fully patched. Rich: you need to rename (in a console) the non-utf8 path to utf8. Something like mv Jos<tab> José González where <tab> is you pressing the Tab key. Qt forces us to know the encoding of filenames, so they have to use the system encoding (utf8 nowadays, hopefully), or the user has to specify it explicitely (comments #3 and #4, but indeed kio_file probably ignores this). I have the same problem also with local files and unfortunately
it seems the work-around described in #3 does not work in this
case.
Some filenames on my system have not been correctly converted
in the past and contain special characters rather than Umlauts.
E.g. the u-Umlaut ("ü") is normally encoded as a 2 byte
sequence (0xC3,0xBC) on my system which is correctly displayed
in Dolphin or Konqueror. But some old file names contain the
byte 0xFC instead which is displayed as the <?> symbol
described in #6.
When I came across such a file in the past, I just renamed
it in the file manager (konqueror or kfm in older KDEs) and
I think that's one of the jobs a file manager should really
be able of.
In KDE 4.4.1 this does not work neither with Dolphin nor with
Konqueror and I have to open a shell and use the "mv" command...
I can confirm this in 4.4.2 It would be fine if someone could spend some vote for this bug. I also find this bug very annoying. I often encounter files with umlauts on FTP servers, where I have no chance to rename the file. At my institute, we are also using KDE4. The idea is to make things simple for the users. But there is no advantage in using a nice file manager, when every one and then it is not able to get remote files. So the users have to know about another method of getting them, and it would be easier to teach them only this method, even if it is not as comfortable as dolphin. BTW, why is this bug still unconfirmed, nearly a year after it had been reported? It's not really hard to reproduce. *** This bug has been confirmed by popular vote. *** Confirm it on Doplhin 1.7 KDE 4.7.2 *** Bug 213306 has been marked as a duplicate of this bug. *** *** This bug has been marked as a duplicate of bug 173097 *** |