# [rfc] (K)Urls and network paths on Windows

Jaroslaw Staniek js at iidea.pl
Wed Jul 2 08:21:28 BST 2008

Thiago Macieira said the following, On 2008-07-01 23:59:
> Jaroslaw Staniek wrote:
>> Hello,
>> I've commited stuff (the last one is r826929) for handling Windows
>> network paths like \\host\path\to\file in KUrl ctors, in the same way
>> as absolute paths with drive letters. The KUrl objects created this way
>> have file protocol, and network paths selected in, say, native file
>> dialogs, work ok now. KUrl values of these dialogs can be used with KIO
>> in apps without any changes now, because file KIO slave is used.
>>
>> This reminds me another set of small decissions we have to make.
>> Anything like open()/fopen() works with network paths on Windows,
>> because of deep integration of the proprietary local network
>> infrastructure in the native API.
>>
>> 1. So perhaps we could have KUrl::isLocalFile("\\\\foo\\bar") == true?
>
> This should be using forward slashes. Internally, everything should be
> forward slashes. The conversion should happen on user input and output as
> well as OS API access.

True. That was mistake in my example only; we handle stuff using '/' internally.

>> Such extended meaning of "local file" would have a number of
>> implications, e.g. KUrl::equals() would work better, since "local"
>> files are case insensitive. It's what we expect.
>
> If, by "local file" you mean something that can be opened with open(2) or
> QFile, then yes, it should return true. Mind you that there should be
> also a mapping in toLocalFile and fromLocalFile.

OK

>> 2. Patrick has mentioned that we could also map smb:// to
>> file://-with-network-paths. Example benefit of such mapping is that on
>> Windows we could share any configuration file coming from UNIX, where
>> smb:// is used. Good for mixed environment in offices.
>
> Good point, but not in KUrl. That's the wrong place.

Yes, this point was put here BTW.

> The file ioslave has code to redirect to another ioslave if necessary, on
> Unix. I guess on Windows it'll be the other way around: the smb ioslave
> redirects back to file.

yes

>> 3. Mapping for the opposite direction (\\ -> smb://) is already here
>> IIRC (?) The only thing special for Windows in this case would be that
>> our GUIs could display \\foo\bar paths instead smb://
>> (of course by default, this can be altered by setting the forthcoming
>> "Geek/Unix mode" :).
>>
>
> I don't understand the third point. I don't see why Windows users would
> want to see smb:// anywhere.

So please forget part 3. at least for a while, it was an effect of previous
IRC discussion.