This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygstart.exe can't open file:///C:/

Thanks for clarification, guys! Indeed it was my bad for including
customary three forward slashes. Both file://C:/ and file://./C:/ do
work with cygstart.
Appreciate the help.

On 7 July 2016 at 20:43, Andrey Repin <> wrote:
> 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,, [::1] do not,
>> whereas $BROWSER file://{,.,localhost,,::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:
> FAQ:         
> Documentation:
> Unsubscribe info:

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]