Re: BUG: Ability to access nonexistent directories
On 5/21/2013 2:18 AM, Christopher Faylor wrote: On Tue, May 21, 2013 at 10:07:03AM +0400, Fedin Pavel wrote: 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). By the way... Right now i'm testing 64-bit Cygwin, and it appears to be significantly faster. I wonder, did you do anything special to achieve this ? Or does this mean just that 32-bit API on 64-bit Windows is slow ? The 64-bit port employed fewer hippos. As it turns out, they were terrible coders. And hippos aside (I think we all know how difficult it is to do that!), 64-bit proggies on 64-bit CPUs are supposed to be a little zippier anyway. -- 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
Re: BUG: Ability to access nonexistent directories
On Tue, May 21, 2013 at 10:07:03AM +0400, Fedin Pavel wrote: >> 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). > > By the way... Right now i'm testing 64-bit Cygwin, and it appears to be >significantly faster. I wonder, did you do anything special to achieve this >? Or does this mean just that 32-bit API on 64-bit Windows is slow ? The 64-bit port employed fewer hippos. As it turns out, they were terrible coders. -- 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
RE: BUG: Ability to access nonexistent directories
> 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). By the way... Right now i'm testing 64-bit Cygwin, and it appears to be significantly faster. I wonder, did you do anything special to achieve this ? Or does this mean just that 32-bit API on 64-bit Windows is slow ? Kind regards -- 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
Re: BUG: Ability to access nonexistent directories
On 5/20/2013 11:58 AM, Andy Hall wrote: 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. As you say, it's a naive question. Just checking around the web for information on "bypass traverse checking" would help you understand things better. This setting is on by default for Windows users. This defines the behavior of how paths are traversed in Windows. When the flag is enabled, Windows allows a user to traverse through directories that he/she has no rights to use in any other way. A side-effect is that it doesn't even check if the directory in question exists. Don't believe me? Try the below in a command prompt (i.e. cmd.exe): C:\tmp>mkdir -p a\c C:\tmp\a\c>dir a Volume in drive C is Default Volume Serial Number is Directory of C:\tmp\a\c C:\tmp\a\c>dir a\b The system cannot find the file specified. C:\tmp>cd a\b\..\c C:\tmp\a\c> So I think we can take Corinna's assessment of how Windows manages things in this case as valid. -- 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
Re: BUG: Ability to access nonexistent directories
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
RE: BUG: Ability to access nonexistent directories
> 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 Corrinas 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
Re: BUG: Ability to access nonexistent directories
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
RE: BUG: Ability to access nonexistent directories
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 ? Kind regards. -- 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
Re: BUG: Ability to access nonexistent directories
On Sat, May 18, 2013 at 1:01 PM, Christopher Faylor wrote: > On Sat, May 18, 2013 at 04:58:18PM +, Stephan Mueller wrote: >>" On May 17 16:45, Warren Young wrote: >>" > On 5/17/2013 12:00, Corinna Vinschen wrote: >>" > > >>" > >Is that ENOFEL or EFLOCK? >>" > >>" > It depends. ENOFEL is the BSD way, but POSIX standardized the SysV >>" > error constant, EFLOCK. Linux supports both, of course, so Cygwin >>" > should, too. >>" >>" Hmm. I'm not too keen to add an error message fome something which >>" could be fixed instead. Maybe we should consider to get us a cat >>" instead? >> >>So, you recommend re-installing the coreutils package, then? > > I think we're now starting to litter this ml with indirect puns. > Yea, my inbox is starting to smell and the litter is highly suspect. > Perhaps we should paws to reflect if this is really wise. > Watchout CGF is ready to bring out the claws in the fine print of the mailing list use statement. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Re: BUG: Ability to access nonexistent directories
On Sat, May 18, 2013 at 04:58:18PM +, Stephan Mueller wrote: >" On May 17 16:45, Warren Young wrote: >" > On 5/17/2013 12:00, Corinna Vinschen wrote: >" > > >" > >Is that ENOFEL or EFLOCK? >" > >" > It depends. ENOFEL is the BSD way, but POSIX standardized the SysV >" > error constant, EFLOCK. Linux supports both, of course, so Cygwin >" > should, too. >" >" Hmm. I'm not too keen to add an error message fome something which >" could be fixed instead. Maybe we should consider to get us a cat >" instead? > >So, you recommend re-installing the coreutils package, then? I think we're now starting to litter this ml with indirect puns. Perhaps we should paws to reflect if this is really wise. 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
RE: BUG: Ability to access nonexistent directories
" On May 17 16:45, Warren Young wrote: " > On 5/17/2013 12:00, Corinna Vinschen wrote: " > > " > >Is that ENOFEL or EFLOCK? " > " > It depends. ENOFEL is the BSD way, but POSIX standardized the SysV " > error constant, EFLOCK. Linux supports both, of course, so Cygwin " > should, too. " " Hmm. I'm not too keen to add an error message fome something which " could be fixed instead. Maybe we should consider to get us a cat " instead? So, you recommend re-installing the coreutils package, then? stephan();
Re: BUG: Ability to access nonexistent directories
On Sat, May 18, 2013 at 4:28 AM, Corinna Vinschen wrote: > On May 17 16:45, Warren Young wrote: >> On 5/17/2013 12:00, Corinna Vinschen wrote: >> > >> >Is that ENOFEL or EFLOCK? >> >> It depends. ENOFEL is the BSD way, but POSIX standardized the SysV >> error constant, EFLOCK. Linux supports both, of course, so Cygwin >> should, too. > > Hmm. I'm not too keen to add an error message fome something which > could be fixed instead. Maybe we should consider to get us a cat > instead? And name the cat Bill. Then the error could be named ENOBILL. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Re: BUG: Ability to access nonexistent directories
On May 17 16:45, Warren Young wrote: > On 5/17/2013 12:00, Corinna Vinschen wrote: > > > >Is that ENOFEL or EFLOCK? > > It depends. ENOFEL is the BSD way, but POSIX standardized the SysV > error constant, EFLOCK. Linux supports both, of course, so Cygwin > should, too. Hmm. I'm not too keen to add an error message fome something which could be fixed instead. Maybe we should consider to get us a cat instead? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
Re: BUG: Ability to access nonexistent directories
On 17/05/2013 5:28 PM, Earnie Boyd wrote: On Fri, May 17, 2013 at 2:09 PM, Christopher Faylor wrote: So it sounds like we may have a feline inavailability deadlock. Is that ENOFEL or EFLOCK? I think it's ENOPURR . ROFLMAO. Maybe ENOMEW would be better. ENOFUR. -- 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
Re: BUG: Ability to access nonexistent directories
On 5/17/2013 12:00, Corinna Vinschen wrote: Is that ENOFEL or EFLOCK? It depends. ENOFEL is the BSD way, but POSIX standardized the SysV error constant, EFLOCK. Linux supports both, of course, so Cygwin should, too. -- 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
Re: BUG: Ability to access nonexistent directories
On Fri, May 17, 2013 at 2:09 PM, Christopher Faylor wrote: >>> >>> So it sounds like we may have a feline inavailability deadlock. >> >>Is that ENOFEL or EFLOCK? > > I think it's ENOPURR . ROFLMAO. Maybe ENOMEW would be better. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Re: BUG: Ability to access nonexistent directories
On Fri, May 17, 2013 at 08:00:22PM +0200, Corinna Vinschen wrote: >On May 17 13:48, Christopher Faylor wrote: >> On Fri, May 17, 2013 at 05:22:06PM +0200, Corinna Vinschen wrote: >> >On May 17 10:56, Christopher Faylor wrote: >> >> On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: >> >> >On May 17 12:56, Fedin Pavel wrote: >> >> >> Hello! >> >> >> >> >> >> > The reason for this behaviour has been outlined a couple of times on >> >> >> > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, >> >> >> > for instance. >> >> >> >> >> >> 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? >> > >> >I would love to, but unfortunately I have to brush my cat on Thursday. >> >And I don't even have a cat. >> >> You're welcome to brush mine in that case. I don't have one either. >> >> So it sounds like we may have a feline inavailability deadlock. > >Is that ENOFEL or EFLOCK? I think it's ENOPURR . 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
Re: BUG: Ability to access nonexistent directories
On May 17 13:48, Christopher Faylor wrote: > On Fri, May 17, 2013 at 05:22:06PM +0200, Corinna Vinschen wrote: > >On May 17 10:56, Christopher Faylor wrote: > >> On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: > >> >On May 17 12:56, Fedin Pavel wrote: > >> >> Hello! > >> >> > >> >> > The reason for this behaviour has been outlined a couple of times on > >> >> > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, > >> >> > for instance. > >> >> > >> >> 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? > > > >I would love to, but unfortunately I have to brush my cat on Thursday. > >And I don't even have a cat. > > You're welcome to brush mine in that case. I don't have one either. > > So it sounds like we may have a feline inavailability deadlock. Is that ENOFEL or EFLOCK? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
Re: BUG: Ability to access nonexistent directories
On Fri, May 17, 2013 at 05:22:06PM +0200, Corinna Vinschen wrote: >On May 17 10:56, Christopher Faylor wrote: >> On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: >> >On May 17 12:56, Fedin Pavel wrote: >> >> Hello! >> >> >> >> > The reason for this behaviour has been outlined a couple of times on >> >> > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, >> >> > for instance. >> >> >> >> 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? > >I would love to, but unfortunately I have to brush my cat on Thursday. >And I don't even have a cat. You're welcome to brush mine in that case. I don't have one either. So it sounds like we may have a feline inavailability deadlock. 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
Re: BUG: Ability to access nonexistent directories
On 17/05/2013 11:22 AM, Corinna Vinschen wrote: On May 17 10:56, Christopher Faylor wrote: On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: On May 17 12:56, Fedin Pavel wrote: Hello! The reason for this behaviour has been outlined a couple of times on this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, for instance. 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? I would love to, but unfortunately I have to brush my cat on Thursday. And I don't even have a cat. Be careful! Invisible cat fur is the worst, it's nearly impossible to get off your black pants. Ryan -- 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
Re: BUG: Ability to access nonexistent directories
On May 17 10:56, Christopher Faylor wrote: > On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: > >On May 17 12:56, Fedin Pavel wrote: > >> Hello! > >> > >> > The reason for this behaviour has been outlined a couple of times on > >> > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, > >> > for instance. > >> > >> 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? I would love to, but unfortunately I have to brush my cat on Thursday. And I don't even have a cat. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
Re: BUG: Ability to access nonexistent directories
On Fri, May 17, 2013 at 12:26:55PM +0200, Corinna Vinschen wrote: >On May 17 12:56, Fedin Pavel wrote: >> Hello! >> >> > The reason for this behaviour has been outlined a couple of times on >> > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, >> > for instance. >> >> 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? 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
Re: BUG: Ability to access nonexistent directories
On May 17 12:56, Fedin Pavel wrote: > Hello! > > > The reason for this behaviour has been outlined a couple of times on > > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, > > for instance. > > 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
RE: BUG: Ability to access nonexistent directories
Hello! > The reason for this behaviour has been outlined a couple of times on > this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, > for instance. 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... Kind regards. -- 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
Re: BUG: Ability to access nonexistent directories
On May 17 10:05, Fedin Pavel wrote: > Hello! I have found a bug in Cygwin. It exists at least for several months. > I have updated today but it is still there. > The bug is simple to trigger and verify. Make a directory like: > > mkdir /tmp/test > > Then go to /tmp and execute: > > ls -l /tmp/nonexist/../test The reason for this behaviour has been outlined a couple of times on this list. See http://cygwin.com/ml/cygwin/2013-01/msg00173.html, for instance. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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
