X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.1 required=5.0	tests=BAYES_00,GENERIC_IXHASH,KHOP_THREADED,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,UNRESOLVED_TEMPLATE
X-Spam-Check-By: sourceware.org
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21;KIP:(null);UIP:(null);(null);H:BL2PRD0310HT003.namprd03.prod.outlook.com;R:internal;EFV:INT
X-SpamScore: 1
X-BigFish: PS1(zz98dIc89bhzz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail203-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Stephan DOT Mueller AT microsoft DOT com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook
X-Forefront-Antispam-Report-Untrusted: SFV:SKI;SFS:;DIR:OUT;SFP:;SCL:-1;SRVR:BN1PR03MB088;LANG:en;
From: Stephan Mueller <Stephan DOT Mueller AT microsoft DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: stat() and tilde prefix (was bad bash tab completion)
Date: Mon, 14 Jan 2013 20:24:09 +0000
Deferred-Delivery: Mon, 14 Jan 2013 20:24:00 +0000
Message-ID: <c040ca2ce35648f99318ee341647c241@BN1PR03MB087.namprd03.prod.outlook.com>
References: <5024B4D4 DOT 6080409 AT shaddybaddah DOT name> <50F395D5 DOT 4050201 AT shaddybaddah DOT name> <20130114061747 DOT GB16739 AT ednor DOT casa DOT cgf DOT cx> <20130114100002 DOT GA22039 AT calimero DOT vinschen DOT de> <50F417F9 DOT 8040108 AT shaddybaddah DOT name> <20130114161307 DOT GB8617 AT calimero DOT vinschen DOT de>
In-Reply-To: <20130114161307.GB8617@calimero.vinschen.de>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CYGWIN.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37;CTRY:US;IPV:CAL;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(24454001)(59766001)(77982001)(53806001)(47776002)(44976002)(49866001)(47976001)(4396001)(47736001)(50466001)(33646001)(16676001)(31966008)(46102001)(51856001)(54356001)(50986001)(47446002)(54316002)(56776001)(74502001)(76482001)(56816002)(23676001)(74662001)(6806001)(79102001)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:BL2FFO11HUB030;H:TK5EX14MLTC104.redmond.corp.microsoft.com;LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0726B2D7A6
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id r0EKTrBL010343

On Jan 14 01:17, Christopher Faylor wrote:
" It is a bug.  It's not just "~".  Any nonexistent directory will
" work, like "foo/..".

Corinna wrote:
" And it's a bug which isn't easily fixed.  Since about the dawn of time,
" Cygwin's core path handling evaluates the path in a non-POSIX manner,
" mainly for performance reasons.

and:
" Cygwin would have to check
" the existence of every single path component from left to right to
" emulate the POSIX requirements.  

and:
" The first step of converting a POSIX path to a Windows path is to
" normalize the path.  "." and ".." components are simply dropped:
"
" "a/b/./c"  -> "a\b\c"
"  "a/b/../c" -> "a\c"
"
" Then the path prefix is replaced by the matching mount point.

and:
" Ultimately I would be glad to
" be able to come up with more correct code in Cygwin while not getting
" slower, of course.  But that's wishful thinking for now.

Perhaps (as you may well have already considered):

- replace the path prefix by the mount point first?  (this may be naïve
  on my part, but it's not clear to me that .. early in a path should be able
  to influence which mount point is substituted)
- test directory existence of the component preceding .. before collapsing
  (in the example above) b/.. to nothing.
- trust that for a/b3/b2/b/../../../c, the existence test of a/b3/b2/b
  before collapsing b/.. to nothing implies existence of b2 and b3 so no
  further tests are needed for 'runs' of .. components with enough
  components before them

Understood that this is still going to cause a slowdown because paths with
.. are not uncommon, but it would reduce the number of additional
existence checks from one-per-path-component to one-per-run-of-..,
which means none in the case of paths without .. in them.

stephan();