On 12/06/2025 00:01, 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.
Cygwin is a POSIX layer. In POSIX //x/y is allowed to mean the same as /x/y as it does in Linux or it can give special significance to 'x' in this context.
Cygwin treads a tricky line with backslash. Technically in POSIX it has no special significance - a backslash is not a path separator and is a legitimate character for a directory or file name but for convenience and backwards compatibility sometimes - and others will be able to give you the circumstances better than I - it will attempt to treat the path as a Windows one.
I would think that if you're building something against Cygwin, it's probably best to assume it's POSIX where only forward-slash is special and not try to second-guess.
Just my two penn'orth. -- Sam Edge
OpenPGP_0x8AC2CEBF54528E30.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 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
