From kde-windows  Wed Dec 20 17:30:48 2006
From: Ralf Habacker <ralf.habacker () freenet ! de>
Date: Wed, 20 Dec 2006 17:30:48 +0000
To: kde-windows
Subject: Re: KUrl(QString) fix
Message-Id: <45897348.5000808 () freenet ! de>
X-MARC-Message: https://marc.info/?l=kde-windows&m=116663586908938

David Faure schrieb:
> On Wednesday 20 December 2006 17:38, Ralf Habacker wrote:
>   
>> David Faure schrieb:
>>     
>>> On Wednesday 20 December 2006 17:02, Leonardo Stern wrote:
>>>   
>>>       
>>>> Greetings,
>>>>
>>>> KUrl kurl("file:///foo/bar")
>>>> path() == "/foo/bar"  (not "foo/bar).
>>>>     
>>>>         
>>> The breakage was on windows only, right?
>>> Someone should really run kurltest (from kdecore/tests) on windows (it passes fine on unix).
>>>   
>>>       
>> I had run kurltest and saw that one of the problems is laying deeper in 
>> QUrl. The appended test case show it
>>
>> F:\daten\test\qurltest>debug\test
>> case 1: file:/netaccesstest_README -> /netaccesstest_README
>> case 2: file://netaccesstest_README ->
>> case 3: file:///netaccesstest_README -> /netaccesstest_README
>> case 4: file:/C:/netaccesstest_README -> /C:/netaccesstest_README
>> case 5: file://C:/netaccesstest_README -> /netaccesstest_README
>> case 6: file:///C:/netaccesstest_README -> /C:/netaccesstest_README
>>
>> 1 and 3. looks as excepted and 2. is ignored because of badly formed url. 
>>     
> Yes (well it would be a hostname, in case 2)
>
>   
>> In case 4. and 6. there the path is prefixed by a non expected '/' 
>>     
> Is it really? file:///foo means the path is /foo, that's how urls work, per the RFCs.
> It doesn't matter that foo is "C:/bar".
> mSo getting /C:/bar as path seems normal to me, we just need to be able to handle that....
>   
I understand and this means there is no bug in the Qt code
> Or do you mean that e.g. QFile("/C:/bar") fails? 
yes.

> Since '/' as first char on Windows can't
> possibly mean anything, Qt could just remove it imho... I guess that's the part that's missing.
>
> At the QUrl level it's all fine imho, unless TT can be convinced to standardize on file:///C:/ kind of stuff
> and adjust path() accordingly to match how local paths work on windows - all very un-rfc-like...
>
>   
Thanks for this pointer.

Now it is clear to me where the real problem is. On unix KUrl::path() 
(or QUrl::path()) returns the same path as toLocalFile(). Because of 
that there are many places in the kde code where the returned path from 
KUrl::path() is used as local file path, which it as you said per 
definition *not* a local file path, it is instead the path of the url.

On windows path() and isLocalFile() returns different values. See case 4 
and 6 below


case url:                           path()                         
toLocalFile()
   1: file:/netaccesstest            /netaccesstest                 
/netaccesstest
   2: file://netaccesstest                                          
//netaccesstest
   3: file:///netaccesstest          /netaccesstest                 
/netaccesstest
   4: file:/C:/netaccesstest         /C:/netaccesstest              
C:/netaccesstest
   5: file://C:/netaccesstest        /netaccesstest                 
//c/netaccesstest
   6: file:///C:/netaccesstest       /C:/netaccesstest              
C:/netaccesstest

As result it looks to me that in kde code toLocalFile() should be used 
in every place where the local path of an url is used, not path()

Ralf
>   
_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows