Problematic interpretion of paths starting with double slashes

Problematic interpretion of paths starting with double slashes

[Sven Eden]

Hello everybody,
 
I have a problem with a script that wants to copy a file,
which has a variable paths build from various variables.

The first variable is a possible prefix, the second an
absolute path. If no prefix is needed, the first consists of
just a slash.

What I now see is the following:

--------
# 09:29:17 SEden@CHH0711 ~ >
rm -rf /tmp/foo

# 09:29:37 SEden@CHH0711 ~ >
mkdir -p /tmp/foo

# 09:29:42 SEden@CHH0711 ~ >
touch /tmp/foo/bar

# 09:29:59 SEden@CHH0711 ~ >
cp //tmp/foo/bar /tmp/foo/baz
cp: cannot stat '//tmp/foo/bar': No such file or directory
--------

This puzzled me, because this works perfectly well on every
GNU/Linux (plus WSL) system I tried. Actually it is
completely in order to double any slashes.
This behavior breaks quite some Makefiles...

I am completely aware that §4.13 of the Open Group Base
Specification Issue 7 (IEEE Std 1003.1-2017) reads:
    "If a pathname begins with two successive <slash>
     characters, the first component following the leading
     <slash> characters may be interpreted in an
     implementation-defined manner, although more than two
     leading <slash> characters shall be treated as a single
     <slash> character."

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?

On any Linux system, 'stat -c "%i" / //' would
show the same inode number twice:
--------
stat -c "%2n %f %i" / //
 / 41ed 48976645948727610
// 41ed 48976645948727610
--------

On Cygwin we get:
--------
stat -c "%2n %f %i" / //
 / 41ed 4222124652325260
// 416d 18014896789143535314
--------

I have searched the cygwin mailing list, but all I could find
was some discussion about UNC paths from 1997.


So, what do you think?


Sincerely

Sven


P.S An example of a failing script line is:
https://github.com/gentoo/gentoo/blob/331976f/eclass/toolchain.eclass#L2136

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

Re: Problematic interpretion of paths starting with double slashes

[Adam Dinwoodie]

On Tue, 12 Jun 2018 at 09:53, Sven Eden wrote:
> I have a problem with a script that wants to copy a file,
> which has a variable paths build from various variables.
>
> The first variable is a possible prefix, the second an
> absolute path. If no prefix is needed, the first consists of
> just a slash.
>
> What I now see is the following:
>
> --------
> # 09:29:17 SEden@CHH0711 ~ >
> rm -rf /tmp/foo
>
> # 09:29:37 SEden@CHH0711 ~ >
> mkdir -p /tmp/foo
>
> # 09:29:42 SEden@CHH0711 ~ >
> touch /tmp/foo/bar
>
> # 09:29:59 SEden@CHH0711 ~ >
> cp //tmp/foo/bar /tmp/foo/baz
> cp: cannot stat '//tmp/foo/bar': No such file or directory

This is intended behaviour. Cygwin interprets paths starting with //
as being attempts to access a UNC path; //tmp/foo/bar is an attempt to
access the file/directory "bar" in the "foo" share on the networked
machine "tmp", in the same way as attempting to access \\tmp\foo\bar
from a Windows cmd console or similar. This is documented at
<https://cygwin.com/cygwin-ug-net/using.html#unc-paths>.

Here, Cygwin isn't attempting to emulate Linux, which, as you note,
generally considers a double forward slash at the start of a path as
identical to a single slash. Instead, Cygwin, like Linux, is an
implementation of the POSIX standards. POSIX states "A pathname that
begins with two successive slashes may be interpreted in an
implementation-defined manner", so Cygwin is being POSIX-compliant
here, per <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11>

I think it's very unlikely Cygwin is going to change its behaviour
here; this is documented and well-understood behaviour that other
Cygwin users – myself included – are going to be relying on. If you
want to be able to use your scripts on Cygwin as well as Linux
systems, you'll need to update them to not rely on
implementation-specific behaviour that can vary between POSIX
implementations.

(I could believe you could get buy-in for ways to change the //
behaviour that wouldn't change behaviour for existing users, e.g. by
basing it on setting the CYGWIN environment variable per
<https://cygwin.com/cygwin-ug-net/using-cygwinenv.html>, or possibly
something with the mount table per
<https://cygwin.com/cygwin-ug-net/using.html#using-pathnames>. However
I've no idea whether that would be possible without unacceptable
compromises to performance or similar, and as ever someone has to
volunteer the time to do it.)

Adam

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

Re: Problematic interpretion of paths starting with double slashes

[Eric Blake]

On 06/12/2018 03:53 AM, Sven Eden wrote:
> Hello everybody,
>   
> I have a problem with a script that wants to copy a file,
> which has a variable paths build from various variables.
> 
> The first variable is a possible prefix, the second an
> absolute path. If no prefix is needed, the first consists of
> just a slash.

Then fix your script to provide 3 slashes instead of 2.  Only 2 slashes 
has the magic UNC behavior.

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}

to get portable behavior that always resolves to the root dir instead of 
trying to dereference remote machines under //.

> 
> This puzzled me, because this works perfectly well on every
> GNU/Linux (plus WSL) system I tried.

Just because your script "works" on a number of systems doesn't mean it 
is portable.

> I am completely aware that §4.13 of the Open Group Base
> Specification Issue 7 (IEEE Std 1003.1-2017) reads:
>      "If a pathname begins with two successive <slash>
>       characters, the first component following the leading
>       <slash> characters may be interpreted in an
>       implementation-defined manner, although more than two
>       leading <slash> characters shall be treated as a single
>       <slash> character."

Yes, that's exactly why your script is not portable.  So even though 
Linux has chosen to make "/" and "//" synonymous, Cygwin has not.

> 
> 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.  Better is to fix your 
script to not try accessing '//tmp' in the first place.

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

> P.S An example of a failing script line is:
> https://github.com/gentoo/gentoo/blob/331976f/eclass/toolchain.eclass#L2136

Well, then report that as a bug to the author of that script.

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

Aw: Re: Problematic interpretion of paths starting with double slashes

[Sven Eden]

> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
> Von: "Eric Blake" <eblake@redhat.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

Re: Problematic interpretion of paths starting with double slashes

[Brian Inglis]

On 2018-06-12 07:14, Sven Eden wrote:
>> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
>> Von: "Eric Blake" <eblake@redhat.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

Re: Aw: Re: Problematic interpretion of paths starting with double slashes

[Eric Blake]

On 06/12/2018 08:14 AM, Sven Eden wrote:
>> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
>> Von: "Eric Blake" <eblake@redhat.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

Re: Re: Problematic interpretion of paths starting with double slashes

[Lee]

On 6/12/18, Sven Eden  wrote:
>> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr Von: "Eric Blake"
>> 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.

but it was portable

> Good style is to guarantee, that
> not more than one slash is issued.

Why don't you submit a patch to guarantee that not more than one slash
is issued?
Or submit a bug report that the earlier patch broke portability?

Asking cygwin to change their long standing, posix allowed,
implementation defined behavior seems like the least likely way to get
the problem fixed.

Regards,
Lee

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

Re: Aw: Re: Problematic interpretion of paths starting with double slashes

[Achim Gratz]

Sven Eden writes:
> 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.)

Well, it does break things if both

//this/or/that
/this/or/that

exist and then at some point host "this" becomes unreachable.  So I'd
keep //unc/path to mean just that on principle.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

Re: Aw: Re: Problematic interpretion of paths starting with double slashes

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

On Jun 12 22:01, Achim Gratz wrote:
> Sven Eden writes:
> > 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.)
> 
> Well, it does break things if both
> 
> //this/or/that
> /this/or/that
> 
> exist and then at some point host "this" becomes unreachable.  So I'd
> keep //unc/path to mean just that on principle.

ACK


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Aw: Re: Problematic interpretion of paths starting with double slashes

[Sven Eden]

> Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr
> Von: "Brian Inglis" <Brian.Inglis@SystematicSw.ab.ca>
> On 2018-06-12 07:14, Sven Eden wrote:
> >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
> >> Von: "Eric Blake" <eblake@redhat.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".

I talked about replacing something wrong with something
worse. That's style, not semantics. But I get what you are
meaning. ;-)


> >> 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" ;^>

Interpreting claims, that were never made, into other
peoples statements is not "style".

But that doesn't matter, really. I got his point all right.


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

That is a wonderful idea. Doesn't work with a package
manager as complex as Portage, but its a start.


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


No. I talked about the overhead to do an extra stat if a
regular UNC access attempt fails. The lag on the UNC check
is there anyway if you access non-existent //foo/bar.

So on my currently idle system the average lag is:
$ time for i in $(seq 1 100) ; do stat /foo/bar/$i 2>/dev/null ; done

real 0m3,164s
user 0m0,817s
sys 0m1,120s

=> ~31ms per request.

That can go up on high IO, though.


However, from my two questions, one was answered, and I can
figure out the other just fine by myself.

Q: Can the handling of // be extended to check for / if the
first fails?
A: Yes

Unanswered: Is the relevant stuff to be found in winsup/cygwin?


Thank you very much for your patience and support.


Cheers

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

Re: Problematic interpretion of paths starting with double slashes

[Sven Eden]

> Gesendet: Dienstag, 12. Juni 2018 um 19:56 Uhr
> Von: "Eric Blake" <eblake@redhat.com>
> On 06/12/2018 08:14 AM, Sven Eden wrote:
> 
> Good style is nice, but in my book, it is trumped by correct code.

Yeah. Point taken. :-D


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

*sigh* ... you are absolutely correct of course.

In hindsight, I interpreted more into written words than was
available. I am sorry and apologize for being so "touchy". 


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

Hmm... that's a good point. So implemeting such a fallback
can only be done for anything that is at least "//foo/".


> > Am I right that the relevant stuff can be found in
> > winsup/cygwin?
> 
> Yes.

Then I'll add experimenting with that idea on my TODO list.


Thank you very much!


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

Aw: Re: Re: Problematic interpretion of paths starting with double slashes

[Sven Eden]

> Gesendet: Dienstag, 12. Juni 2018 um 20:02 Uhr
> Von: Lee <ler762@gmail.com>
> On 6/12/18, Sven Eden wrote:
> > Good style is to guarantee, that
> > not more than one slash is issued.
> 
> Why don't you submit a patch to guarantee that not more than one slash
> is issued?

Already done.


> Or submit a bug report that the earlier patch broke portability?

Already done.


> Asking cygwin to change their long standing, posix allowed,
> implementation defined behavior seems like the least likely way to get
> the problem fixed.

I never did that. All I did was to ask whether such an
extension would be possible.
It is, so my question is answered.

And btw., the implementation, if extended in the way I
proposed, would still be POSIX compliant. ;-)


Cheers

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

Re: Problematic interpretion of paths starting with double slashes

[Sven Eden]

> Gesendet: Mittwoch, 13. Juni 2018 um 10:09 Uhr
> Von: "Corinna Vinschen" <corinna-cygwin@cygwin.com>
> On Jun 12 22:01, Achim Gratz wrote:
> > Sven Eden writes:
> > > 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.)
> >
> > Well, it does break things if both
> >
> > //this/or/that
> > /this/or/that
> >
> > exist and then at some point host "this" becomes unreachable. So I'd
> > keep //unc/path to mean just that on principle.
> 
> ACK
> 


True, if /this isn't just a mount point for //this, meaning
that the "that"s are two different files.

Apart from the urge to question the sanity of anybody
setting something up like that, I see that this is a serious
objection to consider.

I mean, seriously, something like that *is* prone to typos,
and whoever does that will end up manipulating/using the
wrong file rather often anyway.

Which leads to the point that such a setup makes injecting
not mounted network shares like that quite dangerous...

Just my thoughts... Doesn't matter anymore anyway, as my main
question of interest was answered. ;-)

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

Re: Problematic interpretion of paths starting with double slashes

[Andrey Repin]

Greetings, Sven Eden!

>> Gesendet: Dienstag, 12. Juni 2018 um 18:28 Uhr
>> Von: "Brian Inglis" <Brian.Inglis@SystematicSw.ab.ca>
>> On 2018-06-12 07:14, Sven Eden wrote:
>> >> Gesendet: Dienstag, 12. Juni 2018 um 13:52 Uhr
>> >> Von: "Eric Blake" <eblake@redhat.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".

> I talked about replacing something wrong with something
> worse. That's style, not semantics. But I get what you are
> meaning. ;-)

If it is documented, it is not wrong.


> However, from my two questions, one was answered, and I can
> figure out the other just fine by myself.

> Q: Can the handling of // be extended to check for / if the
> first fails?
> A: Yes

Can? Yes. Purely technically. But for consistency it will not be.
Ambiguous paths are a big no-no.


-- 
With best regards,
Andrey Repin
Wednesday, June 13, 2018 15:48:59

Sorry for my terrible english...


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

Re: Problematic interpretion of paths starting with double slashes

[Achim Gratz]

Sven Eden writes:
> True, if /this isn't just a mount point for //this, meaning
> that the "that"s are two different files.
[…]

Again, my main objection is that the interpretation of a path should not
change based on the availability or non-availability of any host (or its
name resolution) over the network.  That's exactly the kind of thing
that will come back to bite you in the most inconvenient moment.

Regarding the discussion about Linux behaviour, I'd be happy if Linux
had an option to just make any path with two leading slashes throw an
error if that path makes it anywhere a local filesystem gets involved.
That'd be quite helpful in quickly weeding out portability problems like
the one you showed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

Re: Problematic interpretion of paths starting with double slashes

[Brian Inglis]

On 2018-06-13 02:34, Sven Eden wrote:
> However, from my two questions, one was answered, and I can
> figure out the other just fine by myself.
> Q: Can the handling of // be extended to check for / if the
> first fails?
> A: Yes
> Unanswered: Is the relevant stuff to be found in winsup/cygwin?

Look at:
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob_plain;f=winsup/cygwin/fhandler_netdrive.cc;hb=HEAD

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