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:mime-version:message-id:from:to:subject
	:content-type:date:in-reply-to:references; q=dns; s=default; b=l
	W+coYPgAZ89ddYjUi4+LjKfakhZa/3iBxncD/zxAUeonn/kJW/v404h6us7GGiVE
	Qnns1zV4DONSN5E4HImEJkr0n5Nkl/a+gKBpdqxjgeozMzju8MQWfPSFTSMfg3CV
	fQ/CmaS+W2dRT/eDX7foH9KgNjKDl+aHKwcWSTw8a4=
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:mime-version:message-id:from:to:subject
	:content-type:date:in-reply-to:references; s=default; bh=DOgRh0X
	Xn3uo3wEwPZzFWwsFKnY=; b=arr3Z5DQ5Ni/AS2WQ5YVulT0apJ20vQFlJIG9na
	ipDHGz9THHEfsweOb4rjME5imBhqzPdc6kUBK/FPTO1KbNoWswngoo69GSlFv3+F
	qKkeSnahOqlDArBG4NqWJNQjC2Szxf/AgWwdQp4VKkvPn0YcTA00kVC6kbUH895S
	dkWY=
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=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=cool, suffer, attacks, lag
X-HELO:	mout.gmx.net
MIME-Version:	1.0
Message-ID:	<trinity-2aa37c55-032a-4631-9d8f-657ecd85e170-1528809265158@3c-app-gmx-bs08>
From:	"Sven Eden" <sven DOT eden AT gmx DOT de>
To:	cygwin AT cygwin DOT com
Subject:	Aw: Re: Problematic interpretion of paths starting with double slashes
Date:	Tue, 12 Jun 2018 15:14:25 +0200
Sensitivity:	Normal
In-Reply-To:	<dc8418d2-2004-97f0-2d8c-ab438f007eba@redhat.com>
References:	<trinity-82173dac-d842-4a87-8d1f-bed9a958d178-1528793630066 AT 3c-app-gmx-bs08> <dc8418d2-2004-97f0-2d8c-ab438f007eba AT redhat DOT com>
X-UI-Message-Type:	mail
X-IsSubscribed:	yes

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


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


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


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

Regards

Sven

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