[Development] The life of a file name and other possibly mal-encoded strings on non-Windows systems

[Kuba Ober]

On Oct 6, 2014, at 11:21 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Monday 06 October 2014 11:12:57 Kuba Ober wrote:
>> Thus, how does Qt deal with a directory listing with such “invalid” file
>> names? Do they survive the round-trip through a QString and QDirIterator?
>> Would it be worthwhile to tackle this issue in a better fashion (whatever
>> it might be) for Qt 6?
> 
> File names that cannot be decoded using the locale codec are considered 
> filesystem corruption and are silently dropped. They won't appear in directory 
> listings.
> 
> This was discussed to exhaustion in Qt 5's development process. The conclusion 
> is to remain at status quo since there is no good, technical solution.

I’d think that the solution could be to use a dedicated class for file names, perhaps with a base class for uninterpreted platform strings. One would also need to think about console I/O, since no matter what the encoding is, it’d be nice to remain somewhat at the level of what bare C provides. For example, a C program doesn’t need to know the encoding of file names nor the encoding used by the console - as long as they are one and the same, printing file names will “just work”. That’s of course assuming that the encoding is ASCII-compatible.

So, I’m specifically thinking of:

1. Retaining platform-specific representation of a file name in a class like QFileName (it’d be a QString wrapper on Windows, for example).

2. Sending it out to `QTextStream(stdout)`, and inputting it from `QTextStream(stdin)`.

3. Using the platform representation in addition to visible representation in the filesystem model.

Would something like that have any chance of getting accepted into Qt 6, if done “properly”? Obviously I haven’t thought out the details yet and there may be a need for several prototypes before it turns into anything remotely acceptable.

Cheers, Kuba