Problematic interpretion of paths starting with double slashes

Sven Eden
Tue Jun 12 11:45:00 GMT 2018

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?



P.S An example of a failing script line is:

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list