This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: BUG: Ability to access nonexistent directories
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 20 May 2013 12:26:20 -0400
- 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>
- Reply-to: cygwin at cygwin dot com
On Mon, May 20, 2013 at 03:53:16PM +0400, 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 ?
Perhaps you should check the archives. This isn't a new idea.
cgf
--
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