This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BUG: Ability to access nonexistent directories

On 5/20/2013 7:53 AM, Fedin Pavel wrote:

  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. :-)



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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]