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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=raBleZIWBttcleYY
	RVlcHPZdJH810JoMXi1GgcoejgGlmfb9xxnUy1ECe+8+MQj+fbump5OEPHQZQbgr
	DzHusvtXfJ46RcppHZQFm3wq8SkI+inKy7ya8hsGxTnhecwZ9nVm3Cwwi1eq7DIx
	U862fr439dPA5HHqui6dkAL30l4=
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:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=wXa4FxQMKWH1Ob4J4NRUH+
	fAGx0=; b=RVqpictlGnZ1dLgS68zK/gO0MFiP9V7fkf6Jm1o5A+so5j5sy/Nv1g
	jyJWJ+JuZ0esW83OfW+byeqifpmRNrhHYxzDwuthjPzzHYZukHJ/HL1ciMiSrQoJ
	fVTI/QUpFL/hQJm9rhYF8TRyGqiAo6dZCYQOm50eAATBwUMIA0WBA=
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.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=book, bending, upset, improving
X-HELO:	mx1.redhat.com
Subject:	Re: Aw: Re: Problematic interpretion of paths starting with double slashes
To:	cygwin AT cygwin DOT com, sven DOT eden AT gmx DOT de
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:	Eric Blake <eblake AT redhat DOT com>
Message-ID:	<7a4567bc-3312-2da5-9e74-46afafa09fc1@redhat.com>
Date:	Tue, 12 Jun 2018 12:56:58 -0500
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; 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-IsSubscribed:	yes

On 06/12/2018 08:14 AM, 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.

Good to know!

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

Good style is nice, but in my book, it is trumped by correct code. 
Since three slashes always behaves identically to one slash, it's handy 
to know that bending style gets you a construct where you no longer have 
to worry about what the user may have passed in through variables, even 
if it is stylistically a bit more verbose than a form that uses minimal /.

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

Hey, let's all assume good intent here.  I did not mean what I wrote as 
an attack against you, nor am I accusing you of writing the said code, 
only that the code you are trying to use (shorthand "your code") is 
relying on something non-portable, and is therefore worth improving, 
regardless of whether Cygwin also makes a change.  I apologize if my 
words have come across in a different tone than intended (email tends to 
be a lousy medium in that regards).  And likewise, I'm not upset at your 
reaction to my words.

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

Indeed, and you may have a valid argument for making that change in 
Cygwin; patches are certainly welcome (that is, since //tmp is already 
implementation-defined behavior, we can define it to attempt to resolve 
to the remove host first, and on ENOENT then attempt to resolve it 
locally).  It does have one potential minor drawback: right now, at 
least bash hard-codes the assumption that on Cygwin, //foo and //foo/ 
resolve identically (that is, IF //foo exists, it necessarily behaves as 
a directory), using that assumption to reduce the need for network 
queries during certain forms of tab completion.  If we add the fallback 
to trying /foo, that assumption is no longer always the case (it could 
be a regular file, symlink, socket, ...).

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

Yes, you've got that part right.

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

Yes.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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