Re: Problematic interpretion of paths starting with double slashes

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot 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".

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