On Wed, 11 Jun 2025, 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?!? -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
