X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Pd9SMtxH1x7WmRIx
	6jJGWq3zfuDXUU/yzIRxpGa+gPybijaJpdDubsk4mtkOi0XuN6CBOB9RxmexofHq
	a5W0j9EhTpIbmbzc8bmN/1Pg+wpObVWpDpIgC1JujBRu6zjYpiHh1rFCDmdDu11T
	R5kDooonZRp1G3DAeUwqpkSxH0g=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=KXlNMQJZ4zUmVYWs3Lgj0s
	IP0mo=; b=uR+TZ9XzvsWF6zkVMwZj69fAzS2ka0jCsZoBkA6P/tyKkxTce7GMJc
	//0nSFcVBOR39sYiXWhSveL8qg9dR80M+gliEr40VxdZiV1dSIn3xIt4DFxuDMMn
	2LHPtCPlN76g5QT3+FWjdV4VIPz5KSDzITNoSfCNVmSdDkqOIALBg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Single, H*UA:10.0, H*u:10.0, H*Ad:D*ab.ca
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.3 cv=PvS9kTE3 c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=20KFwNOVAAAA:8 a=EJsovmrbzapQHRGv3oYA:9 a=UpCUsghKHMFbxk1L:21 a=waWMMazKQHSPVqCs:21 a=QEXdDO2ut3YA:10
Reply-To:	Brian DOT Inglis AT SystematicSw DOT ab DOT ca
Subject:	Re: Problematic interpretion of paths starting with double slashes
To:	cygwin AT cygwin DOT com
References:	<trinity-82173dac-d842-4a87-8d1f-bed9a958d178-1528793630066 AT 3c-app-gmx-bs08> <dc8418d2-2004-97f0-2d8c-ab438f007eba AT redhat DOT com> <trinity-2aa37c55-032a-4631-9d8f-657ecd85e170-1528809265158 AT 3c-app-gmx-bs08>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Openpgp:	preference=signencrypt
Message-ID:	<00de90b8-a2b4-f751-1ef2-05645a3f1119@SystematicSw.ab.ca>
Date:	Tue, 12 Jun 2018 10:28:52 -0600
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version:	1.0
In-Reply-To:	<trinity-2aa37c55-032a-4631-9d8f-657ecd85e170-1528809265158@3c-app-gmx-bs08>
X-CMAE-Envelope:	MS4wfL/O04XxrFn1Dc8bHNrBh8Mce7Aggr4LdpyvJScNv9BNKHBV9tqGJ18P+r7/Jx4tutF7H+4OwC32Zg4xsYUoqE2JjmwYGXhR4IHzWhlU7+PdBppgK9aR 2s4uwMj8CZumUk7ZEB9dtqe3t49Asekb0r8mw0cOf6Xn46N7ENd8QhCltowBXEsYFmC5umkZ5ndBMw==
X-IsSubscribed:	yes

On 2018-06-12 07:14, Sven Eden wrote:
>> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
>> Von: "Eric Blake" <eblake AT redhat DOT com>
>> Then fix your script to provide 3 slashes instead of 2. Only 2 slashes
>> has the magic UNC behavior.
> It is not my script. *my* scripts are portable by all means.
>> That is, if you have a script that is concatenating:
>> ${prefix}/${dir}
>> where ${prefix} might be empty, you can always rewrite it to be:
>> ${prefix}///${dir}
> The script was "fixed" from ${prefix}/${dir} a while ago. Before that the 
> outcome was "///". Which is very bad style. Good style is to guarantee, that
> not more than one slash is issued.

Which is equivalent to //localhost/ on Cygwin and elsewhere - / on Linux - this
is semantics not "style".

>> Just because your script "works" on a number of systems doesn't mean it
>> is portable.
> I neither wrote it was my script, nor that it was portable per se. But
> thanks for jumping down my throat for nothing. I won't quote and answer to
> your further attacks, but instead concentrate on the relevant stuff, okay?

Eric contributes to The Open Group Single Unix Spec and elsewhere and provides
these explanations frequently - that's his "style" ;^>

>>> My question therefore is, whether the behavior can be gotten
>>> nearer what every other GNU/Linux system does.
>>> Maybe, if said first component can not be resolved as an smb
>>> host, try an absolute path instead?
>> That won't work as nicely as you want, because you will introduce long
>> timeouts for every time that Cygwin first has to ascertain that '//tmp'
>> does not exist as a remote host. Maybe we could indeed make '//tmp'
>> resolve to '/tmp' if there is no remote '//tmp' available, but the speed
>> penalties in doing so will not make it pleasant. 
> The speed penalties would only apply if
>   a) "Something" looks up //foo/bar
>   b) "Something" made a mistake and actually wanted
>      /foo/bar
> So apart from the speed penalty that "Something" has to suffer, and its their
> own damn fault, the only real consequence would be that "Something" does not
> die from ENOENT any more.

If you can't fix the target, wrap it with another script or function, and run it
with "command script paths...", so it never sees non-POSIX-compliant paths.

>>> I have searched the cygwin mailing list, but all I could find was some
>>> discussion about UNC paths from 1997.
>> Yes, we've had special support for // as UNC for a LOOONG time, and
>> changing it now would break existing users that expect it to work as
>> allowed by POSIX.
> Keeping it, changing it, extending it. It doesn't matter. All three variants
> would be fully POSIX compliant. However, I never asked to actually change the
> current behaviour. Only whether it was possible to extend it.
> Looking up // as UNC is the default, wanted and expected behaviour. I got
> that right from the start and even wrote that I find that pretty cool.
> Doing a simple stat on / if (and only if) the UNC lookup fails, does not
> endanger anything. It wouldn't break anything or do any other damage. Besides
> from adding an additional <0.01s lag to any failed access that *really* meant
> a network share.
> So no. Adding this tiny extra functionality wouldn't break anything for
> anybody, but allowed the usage of software that relies on the non-cygwin
> behaviour. (And is outside the users control.)
> Am I right that the relevant stuff can be found in winsup/cygwin?

Overhead is ~2.5s for non-existent share checks on my system:

$ for p in / // ///; do time ls ${p}tmp/foo/bar; done
ls: cannot access '/tmp/foo/bar': No such file or directory

real    0m0.040s
user    0m0.015s
sys     0m0.030s
ls: cannot access '//tmp/foo/bar': No such file or directory

real    0m2.333s
user    0m0.015s
sys     0m0.015s
ls: cannot access '///tmp/foo/bar': No such file or directory

real    0m0.035s
user    0m0.015s
sys     0m0.015s

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

- Raw text -