This is the mail archive of the
mailing list for the Cygwin project.
RE: BUG: Ability to access nonexistent directories
- From: "Andy Hall" <fixpertise-consulting at comcast dot net>
- To: <cygwin at cygwin dot com>
- Date: Mon, 20 May 2013 08:58:47 -0700
- 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> <519A3E58 dot 4010609 at cygwin dot 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 ?
> >> 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
> > thing like /foo/bar/../baz, we really need to check for intermediate
> > 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
> > 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
> code because of its complexity already and its high use. Even what
> 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
> corner cases are cleaned up (your case is a one known example of such
> corner case). So the message is not that folks here don't see the
> in your suggestion or need help figuring out how to minimize the
> What's needed is some code to do this and some good analysis that
> that it doesn't impact performance outside this corner case. Such a
> could then be evaluated directly for any complexity it adds and the
> performance analysis could be used to objectively evaluate any impact
> 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
> There's a difficult balancing act in this code so changes are not
> undertaken lightly. Just fair warning. :-)
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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple