Comment 5 for bug 1011999

By the way, Jean-Michel, I disagree about the cause of this. I'm an ex-internationalization architect, and Qt is sadly just as bad as everything else.

The correct way to deal with path names would be to have a special path name class, specialized into all the different file systems that might exist. Many file systems have no idea about internationalization, storing file and directory names as strings of bytes with no defined or stored encoding (FAT, ext2, ext3 and ext4 are all like this, for example). Such a class would have a function for obtaining a Unicode "display name". This Unicode name would not be used to refer to the file later and may indeed be incorrect; but at least the underlying file name object would still refer to the file correctly even if we can't work out how to display its name properly.

Qt treats file names as Unicode strings, which not only requires (or at least encourages) the user to know (or guess) what the OS conventions are (/, \ or : for example) but also requires a totally unjustified translation to Unicode using the conversion specified in the locale. If the file name is in some other encoding, you might not be able to access the file, because you don't actually know its name.

My fix here will therefore fail to work for any file that has a name that has characters that fail to be decoded by the locale's specified converter. There is no way around this; Qt's code throws away the required information before we can get our hands on it.