[Development] Deprecating QFile::encodeName/decodeName

[João Abecasis]

Thiago Macieira wrote:
> On sexta-feira, 8 de junho de 2012 10.44.37, João Abecasis wrote:
>> I actually think a satisfactory solution would be to add limited support for
>> "file://" local path URLs, where percent encoding would be fully supported
>> as per URL rules. This would only support absolute paths, but would already
>> enable everything in my wish list. For paths generated inside Qt, URL-style
>> paths would only be used where the path couldn't otherwise be decoded to
>> QString.
> 
> Hmm... that's actually not a bad idea.

We're getting somewhere! :-)

> By doing this, we'd be making it impossible to have a filename whose name 
> starts with "file:///". That's a problem we need to document if we do it (note 
> that such a file cannot exist on windows in the first place). However, such files 
> already *do* pose problems, since many applications will try to decode a URL 
> if they find one, falling back to a path otherwise. See the discussion on 
> QUrl's constructor and the example of KUrl's and KUrl::fromPathOrUrl.

A file whose name starts with "file:///" could still be fully understood by prefixing it with "./". This is not very different from what a user needs to do to ensure a file name is not confused with a command line option (when passing it in the command line, that is).

Security issues can me minimized by requiring absolute paths where this is a concern.

>>> However, I cannot agree with bringing the setter functions back. I do
>>> agree
>>> with removing them completely, though.
>> 
>> Go for it, already!
> 
> You're the one who wants this. I'm perfectly happy leaving them as it is :-)

I thought this was feedback you already got in the review of your patch :-p

Cheers,


João