This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: Message Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] [Date Prev] [Date Next] [Thread Prev] [Thread Next] [Raw text]

# Re: Problematic interpretion of paths starting with double slashes

• To: cygwin at cygwin dot com
• Date: Tue, 12 Jun 2018 11:00:44 +0100
• Subject: Re: Problematic interpretion of paths starting with double slashes
• References: <trinity-82173dac-d842-4a87-8d1f-bed9a958d178-1528793630066@3c-app-gmx-bs08>

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