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:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=ipeIBaQTWcU0BG0c
	qAWoNi23PWXqRj+hSPp0a9vKGOsYb6E4QdY7d22ATXjd40+Jujnr7R3d0/U9Ym6P
	ZEhH58gQpWaKngpvCzOyVlJr8g2oa1rq0fW99tOq5+0d0Bzd9lSMxa0jHTIa5gSx
	xUAdpKMaOzzwPR/6gZaTa+A59TM=
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:message-id:date:from:reply-to:mime-version:to
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=kZzDIPu5tG3b49S6I2WQXS
	JZiEg=; b=pYeVMfi+r0GftspiojRujPwL5HJMhTNrEHjgSC0rRVfh0XBMdz41US
	ou3os2aUzMY+012eByrxdRPsfeGOr+tqUfxCfrTRMqbPI5m6LWfNY7Yj9srCEUos
	SUjl+YuMOp/TgQeQUNCUIskLHj+vse8ZfKWLUv0GUE18hLSTOLpYc=
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=2.1 required=5.0 tests=AWL,BAYES_00,BOTNET,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE autolearn=no version=3.3.1
Message-id:	<519A3E58.4010609@cygwin.com>
Date:	Mon, 20 May 2013 11:16:40 -0400
From:	"Larry Hall (Cygwin)" <reply-to-list-only-lh AT cygwin DOT com>
Reply-to:	cygwin AT cygwin DOT com
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: BUG: Ability to access nonexistent directories
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>
In-reply-to:	<001a01ce5550$9e20afd0$da620f70$%fedin@samsung.com>

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

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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 -