Version: 3.1.1 (using KDE 3.1.1) Installed from: (testing/unstable) Compiler: gcc version 3.2.3 20030309 (Debian prerelease) OS: Linux (i686) release 2.4.21-pre5 I have two filesystems with reiserfs and ext3. The following problem arises on both filesystems. Originally, I was using the ISO-8859-1 locale, so all the filenames were encoded with ISO-8859-1. Then I changed to Unicode, and so now all the filenames with exotic characters, like the æ, ø and å in the Norwegian language, are displayed with a rectangular box instead of the correct character, but that is understandable. The problem is that I can not manipulate these files inside konqueror. E.g, if I try to rename the file I get the message "The file or directory <filename> does not exist", where <filename> is the real file name with a rectangular box instead of the exotic character. I think that I should be able to manipulate the file from within konqueror even though the locale has changed. emelfm shows the filename correctly after the locale change, and is able to rename and open the file nautilus shows the message (invalid unicode) next to the filename, but is able to open and rename the file Torquil
This is the same infrastructure problem from #50270. Files in KDE use the UDSEntry structure to save its info. And the filename part is saved as a QString, which automatically encodes everything to the current locale. QString is simply a too high-level data structure to be used in the low-level UDSAtom structure. This is a serious desing problem, and I have no idea how it will be solved.
It's true that we'll probably have to add a "unencoded" QCString to the UDSAtom structure, so that we can manipulate entries that don't decode to Unicode. But be aware that it won't always for for local files, since the encoding for them is not set by menus, but by the environment. And URLs are Unicode strings as well.
Maybe we can somehow flag "unencodable" names in QFile::encodeName // QFile::decodeName ?
*** Bug 53164 has been marked as a duplicate of this bug. ***
That would probably solve the cases in which local filenames have non-representable characters and spare us the encoding/decoding hassle I have commented on (i.e., keeping the original filename). There could be other solutions to this flagging, but one way would be to use a non-printable reserved Unicode codepoint as the first character -- or last -- and keeping the original filename in a Latin1-to-Unicode translation. High level programs like Konqueror would recognise this and display a warning next to the file saying so. And as I said in another bug report, we don't have to support an environment encoded half one way and half another way, in which case no apps other than Konqueror would be expected to read files without decodable names.
About mixed support, UNIX command line and Windows support it (I mean, you can at least access the file and rename it). There is no way to support more than 1 encoding, but any KDE app must have the chance, in a high-level fashion, to access the file, encoded in any charset someone can imagine. KFile and KFileItem must be smart enough to return to the developer something usable (I don't mean correct, which is impossible). The ideal world is when a developer can write an app that can open any file, without writing exceptions. The exceptions must be encapsulated inside the framework.
I agree with you that that is the ideal solution. But it's not practical, since we can't represent an unrepresentable filename. Or we add a "hack" to QFile::encodeName. Actually, come to think of it, it might be a way out. About UNIX command-line support: it's 8-bit, so it doesn't apply. If you load it into a Unicode-aware program, there's no guarantee it will keep on working. KDE is Unicode. About Windows support: Windows doesn't have invalid filenames because the system call API is Unicode and filenames are stored in Unicode on disk.
When using utf8 filesystems the problem does not exists. For example, Using a vfat filesystem with utf8 encoding enabled, the problem does not exists. /loopfile.disk /c vfat utf8=true 0 0 Then, unmounting and mounting it with utf8=false, /loopfile.disk /c vfat utf8=false 0 0 the problem is still there (with konqueror and dolphin 4.0.4). The easiest solution is to use filesystems with utf8 encoding. The filenames can be changed from one encoding to another using, for example: http://www.j3e.de/linux/convmv/
Created attachment 26254 [details] a testcase filesystem The attached file contains files copied using konqueror from a ntfs filesystem and a vfat filesystem to an ext3. It includes directories and files. To mount the file and see the contents, use mount -o loop <filename> <mount pount>
All reports about file management mode reported against KDE 3 (konqueror) has been closed: konqueror in KDE 3 is no more developed and mantained. All bugs and wishes which could be interesting for Dolphin in KDE 4 (the new KDE file manager) has been collected into a specific list. Please try the new file manager before request new features and report bugs. Before submitting new reports check carefully the already opened KDE/Dolphin reports in order not to add duplicates. Many thanks.