Problematic interpretion of paths starting with double slashes

Eric Blake
Tue Jun 12 16:28:00 GMT 2018

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:


where ${prefix} might be empty, you can always rewrite it to be:


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:

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

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list