X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding
	:in-reply-to; q=dns; s=default; b=heuNXl21bqEn1qqaaozZP1tS8gGkWG
	wDFU0b+qr9hXpCxLlTIL+cWvKuZvfxiUZM/eZJwCeEjBPL5nVAA9q01Zwj+6rZ/S
	BvPHMzr4rJguN50uTmVLLDVinTkEJQPgEfs3SoVkCkEy7syvaXYcvDHI5+CdspYD
	cqJnjvORB35qc=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:subject:date:message-id
	:mime-version:content-type:content-transfer-encoding
	:in-reply-to; s=default; bh=KXCd6U0E2LjmSifQSrtZbvie1ic=; b=IY0c
	abxkRp/897EUDX5LZy44mnQ0pFJNyznK/qr2aF3uo4nwQpGY3BVAzI7NJ8/1UkHd
	O9B0HlfR5AK3Xf0icEDLyy/Bp/xPtcHOQf+RvxJudxQcDdULJKhg+ldP0aSXY/iy
	fn0w5BbNUBO25gFhINDWKWkvYS+tXuyxS4LezJU=
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
X-Spam-SWARE-Status:	No, score=-4.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1
From:	"Andy Hall" <fixpertise-consulting AT comcast DOT net>
To:	<cygwin AT cygwin DOT com>
References:	<000201ce52c4$891b04c0$9b510e40$%fedin AT samsung DOT com> <20130517083612 DOT GE21752 AT calimero DOT vinschen DOT de> <000d01ce52dc$74e54bb0$5eafe310$%fedin AT samsung DOT com> <20130517102655 DOT GG21752 AT calimero DOT vinschen DOT de> <20130517145612 DOT GC7087 AT ednor DOT casa DOT cgf DOT cx> <001a01ce5550$9e20afd0$da620f70$%fedin AT samsung DOT com> <519A3E58 DOT 4010609 AT cygwin DOT com>
Subject:	RE: BUG: Ability to access nonexistent directories
Date:	Mon, 20 May 2013 08:58:47 -0700
Message-ID:	<AF416313505341088247FB0EF502C1CA@ahallpc>
MIME-Version:	1.0
In-Reply-To:	<519A3E58.4010609@cygwin.com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id r4KFx3eg023456

 
> On 5/20/2013 7:53 AM, Fedin Pavel wrote:
> >   Hello!
> >
> >>>>   Heh...
> >>>>   So, complete emulation would cost a major performance drop,
> right ?
> >>>>   Well... Can there be any setting which enables these checks ?
> At
> >> least we have one use case...
> >>>
> >>> Not without lots of new code.
> >>
> >> So, maybe next Thursday?
> >
> >   By the way, you said it would be slow... I have an idea how to
> implement a
> > compromise solution which would not be horribly slow.
> >   What if we check existence of intermediate paths not every time
> but only
> > when we meet thing like '..' ?
> >   I'll explain... For example, if we would access /foo/bar/baz,
> testing for
> > /foo and /foo/bar existence would supposedly be a waste of time,
> because we
> > would get "Object not found" on the final path too. But, when
> processing
> > thing like /foo/bar/../baz, we really need to check for intermediate
> dirs.
> > But, still not every time. In this example we actually need to test
> only for
> > /foo/bar's existence. I. e. a path to which we apply '..', before
> stripping
> > the last component.
> >   Does it make sense ?
> 
> Sure, that makes some sense.  It might help address the concern of not
> adding lots of new code and minimize the slowdown that the code would
> add.  But there is a clear reticence to fiddle with the path
> processing
> code because of its complexity already and its high use.  Even what
> seems
> like a small slowdown can be magnified because it is called so often.
> Small changes adding new features can add allot of complexity once all
> the
> corner cases are cleaned up (your case is a one known example of such
> a
> corner case).  So the message is not that folks here don't see the
> value
> in your suggestion or need help figuring out how to minimize the
> impact.
> What's needed is some code to do this and some good analysis that
> shows
> that it doesn't impact performance outside this corner case.  Such a
> patch
> could then be evaluated directly for any complexity it adds and the
> performance analysis could be used to objectively evaluate any impact
> there.
> Not to discourage you but there will be a fairly low tolerance for
> much of
> a complexity change or almost any performance degradation.  Cygwin's
> performance is a regular source of complaints on this list (and
> elsewhere).
> There's a difficult balancing act in this code so changes are not
> undertaken lightly.  Just fair warning. :-)
> 
> --
> Larry
> 
> _____________________________________________________________________

So here is a naïve question.  Contrary to Corrina’s posting at
http://cygwin.com/ml/cygwin/2013-01/msg00173.html, the underlying OS
must effectively evaluate a path from left to right. Otherwise it cannot
locate the file in questions.  Now the OS may optimize this in a number
of ways, but in the end, the resulting optimization has to be equivalent
to a left to right evaluation. 

Furthermore, a Windows path can include “.” and “..”, so why not leave
these in for the first attempt to access the file?   Only if that fails,
then start breaking up the path to locate possible symbolic links,
missing directories or deal with other special cases?

Andy Hall


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -