DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:reply-to:message-id:to:subject
	:in-reply-to:references:mime-version:content-type
	:content-transfer-encoding; q=dns; s=default; b=hGMqUMRlKeAM4XUb
	0O6RVBMLkBfZ3/SEuF59t3cELJrVlVpIjyWiHydvcolluw0x77FTjmRLsdnz6AHr
	1nvHOrt95AS+iIsCjaS652HG/rBOlYySltTN255WNBgGshvHoIxNxFkxmrDi5Xzb
	sLV3a/qaexch34DgsZBxY7RE4gA=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 7 Jul 2016 20:43:45 +0300
From: Andrey Repin <anrdaemon@yandex.ru>
Reply-To: cygwin@cygwin.com
Message-ID: <217827636.20160707204345@yandex.ru>
To: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>, cygwin@cygwin.com
Subject: Re: cygstart.exe can't open file:///C:/
In-Reply-To: <loom.20160707T180447-900@post.gmane.org>
References: <CAPTiy3MdAdrLnLY5C3+Ye48=eyha_+XW=CEdZBJHodvxJjsGrA@mail.gmail.com>     <c0862cea-a04a-d50c-e632-33748529090f@gmail.com>   <CAPTiy3MMUfDQjDt9D=OBMdLy7KNGhdS5a3AdHS4coTamDZ7Tww@mail.gmail.com>   <loom.20160705T200540-33@post.gmane.org> <85901248.20160707173235@yandex.ru>  <loom.20160707T180447-900@post.gmane.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Greetings, Brian Inglis!

> Andrey Repin writes:
>>Brian Inglis writes:
>>> cygstart file://C:/ works - read the MS DN and MS KB articles on file URIs
>>> and shlwapi
>> Which isn't quite right. "file:" is a protocol, "//" is the foreign host
> mark, "[.]/" is "current host's filesystem root".
>> So, I guess, the CORRECT solution (or, rather, workaround) would be an
> explicit "." in host name.
>> cygstart "file://./C:/"
>> Works here. Please try it yourself.

> MS approach makes some sense, as the RFCs e.g. 3986 define what you call the
> the "host" as the namespace authority. In Unix systems, you have only one
> unified local namespace (even though the mounted filesystems can have
> radically different namespace rules e.g. fat, ufs, ext?, and the RFCs state
> the authority may be delegated, so the rules can change along the path),
> whereas on Windows, each device represents (possibly virtual e.g. subst)
> separate filesystem namespaces. 

> Where MS approach makes no sense, is that . is a (MS) kludge which works,
> but other local synonyms: null/nothing, localhost, 127.0.0.1, [::1] do not,
> whereas $BROWSER file://{,.,localhost,127.0.0.1,::1}/C{:,\|} displays
> identical contents, differing only in whether a : or | follows the drive
> letter in the address for each tab. 

file://localhost/C:/ works, at least for CMD call. Not for cygstart, though.
Using IP, of course, does not, which, again, makes sense.
Browsers, on the other hand, often have their own protocol translation, so you
can't quite compare their behavior to native API calls.

> I dealt with a Windows product where file: (but not ftp, http, or https) had
> to have an initial cap File: to work. The vendor accepted a bug report but
> made it a doc issue rather than doing a non-compliance fix. The company
> and/or products were traded annually  like an end of career player! 

*sigh*


-- 
With best regards,
Andrey Repin
Thursday, July 7, 2016 20:38:24

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple