DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=phIgvkzxzIj5GSMYwY9wpZas3XF6d07jNC9GFqOfWskO4IwHWgAEN
	oWPcxGgjjlL3h+6o5qVVAom/wSben0xyTYxUZXai9yHUxZYVKUnURz9qCnrcJJuT
	VCDDVml5jSLn4VsmidiWbi4stwaeHahqYLINlTfY3My/byedf2gE5o=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
To: cygwin@cygwin.com
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Subject: Re: cygstart.exe can't open file:///C:/
Date: Thu, 7 Jul 2016 17:01:08 +0000 (UTC)
Lines: 29
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)

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. 

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! 


--
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