DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 55D5ZQOT1054244
Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 55D5ZQOT1054244
Authentication-Results: delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=PdLufoVZ
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 87382382215E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1749792924;
	bh=Sru/kOyMpwedAdtRDa/OFFE7aZW+vsqZP8rY+lHWdPI=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=PdLufoVZvN8e4M099CygioXdlTRlrpPH4jsezGi3a+818XVm+pnN69n/gy6pUdIKq
	 OXwLYZCOGAwjc8oVhEuwSiYk4FDxlfBwFoDFrZlgWfWPezLDYTPz2tHMNWmhmK3y2f
	 1ZMOi1TitL7EI5Ko+5sb55W3A3kSS8LUPJl1QVXQ=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C859385624B
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0C859385624B
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749792898; cv=none;
 b=mEd+fULFYHtuLqC7HaIcHdaPPxBacLEwCzh9Fzk7EPWkj1nHiWaerYQ0sAPzPKfqMP+OXNiDJ+O9xGOa5yM4MbsPzL99BicG5JcbCh5KA41YWa5KtupTA1Rx6VIgZKOdNOFGJb1IqHx7TPFEUrMa1IcZ+0UnLMJBDeZ0dbu4s4I=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1749792898; c=relaxed/simple;
 bh=UXMTnCAFhWnOD97geqtPuxkFF/bYB47y83KwQ0YOBFY=;
 h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
 b=w5RckdHz2Utw7Q1cBvuVi7xRFQCeDLdxs0BMl9hgupyxtmsajH3IFkisp7s26J+09d/QvQcGN2QcrIwqCjIr+smzwtrT0S0/bshQaB7oGJeZ691tu6hUA9bXIKOu2M2x/izM9A4bRnNizhK5p90T/KeJ6I8rag6YfQlyTy2ORDs=
ARC-Authentication-Results: i=1; server2.sourceware.org
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C859385624B
Date: Thu, 12 Jun 2025 22:34:57 -0700 (PDT)
X-X-Sender: jeremyd AT resin DOT csoft DOT net
To: cygwin AT cygwin DOT com
Subject: Re: Path prefix //./ in Cygwin
In-Reply-To: <93fd79f3-bb39-79c2-8e78-57c4af356e54@jdrake.com>
Message-ID: <35feb8a2-17eb-fcc8-48dc-58166f708b1a@jdrake.com>
References: <93fd79f3-bb39-79c2-8e78-57c4af356e54 AT jdrake DOT com>
MIME-Version: 1.0
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Jeremy Drake <cygwin AT jdrake DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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