Path prefix //./ in Cygwin

Fri Jun 13 05:34:57 GMT 2025

On 2025年6月11日, Jeremy Drake via Cygwin wrote:
> While making some tests for a path parser in rust
> (https://github.com/rust-lang/rust/pull/141864), an interesting corner
> case in Cygwin path handling came to light:
>> Works:
> \\.\C:
> //.\C:
> //./C:\foo
>> Doesn't work:
> //./C:
> //./C:/foo
>> It appears to be able to use the \\.\ prefix, there must be at least 1
> backslash in the path. Otherwise, it seems that . and .. are being
> normalized like a normal path and //./C:/foo is treated like
> //C:/foo. The delay attempting to access it makes me think it is looking
> for a server/share style path.
>> My question is whether this behavior is intentional or a bug. I don't
> want to see rust codify this in their path parser and tests, only to have
> it change later as a bugfix in a corner case of path handling.

The docs say
https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
The following paths are treated as native Win32 paths by the Cygwin DLL
(but not necessarily by Cygwin applications):
All paths starting with a drive specifier
 C:\foo
 C:/foo
All paths containing at least one backslash as path component
 C:/foo/bar\baz/...
UNC paths using backslashes
 \\server\share\...
An interesting corner case:
ls -l '/a\b'
is the same as '/a/b', but
ls -l '\a/b'
will refer to X:\a\b where X is the drive letter of the CWD. If the CWD
is /proc (so something without a Windows CWD), it seems to fall back to
referring to '/a/b' again?!?