Re: [1.7] bug in chdir

2009-07-15 Thread Corinna Vinschen
On Jul 15 17:38, Eric Blake wrote: > Corinna Vinschen cygwin.com> writes: > > > I created a patch which uses WNetOpenEnum for the existence check, but > > it needs extremly long to timeout the existence check in such a case. > [...] > So, no obvious speed regression on good paths, a whopping 25%

Re: [1.7] bug in chdir

2009-07-15 Thread Eric Blake
Corinna Vinschen cygwin.com> writes: > I created a patch which uses WNetOpenEnum for the existence check, but > it needs extremly long to timeout the existence check in such a case. There's already a long timeout on unknown names; that's inescapable when dealing with // issues. Without the pat

Re: [1.7] bug in chdir

2009-07-15 Thread Corinna Vinschen
On Jul 15 13:58, Eric Blake wrote: > Corinna Vinschen cygwin.com> writes: > > The fact that accessing //home does not create an > > exception points to a successful SMB name resolution. > [...] > It still seems like chdir() should do some > sort of stat() test rather than just a successful SM

Re: [1.7] bug in chdir

2009-07-15 Thread Dave Korn
Eric Blake wrote: > Corinna Vinschen cygwin.com> writes: > >>> $ ls -dF //eblake //home //bin >>> ls: cannot access //bin: No such file or directory >>> //eblake/ //home/ >>> >>> >>> I guess that means, since //bin failed but //home succeeded, that there is >>> a machine on the domain at my work

Re: [1.7] bug in chdir

2009-07-15 Thread Eric Blake
Corinna Vinschen cygwin.com> writes: > > $ ls -dF //eblake //home //bin > > ls: cannot access //bin: No such file or directory > > //eblake/ //home/ > > > > > > I guess that means, since //bin failed but //home succeeded, that there is > > a machine on the domain at my work which is named home

Re: [1.7] bug in chdir

2009-07-15 Thread Corinna Vinschen
On Jul 15 06:46, Eric Blake wrote: > > If you're able to cd to //home, then there must be some crucial > > difference in your environment. You should debug this, at least with > > strace, so we can find out under what circumstances this occurs. > > (time passes...) > [...] >56 6950464 [main]

Re: [1.7] bug in chdir

2009-07-15 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ashok Vadekar on 7/15/2009 5:23 AM: > Could it be that a mount point called /home, or //home (if possible), makes a > difference? Maybe you're on to something - at work I have: $ mount -m C:/cygwin-2/bin /usr/bin ntfs binary 0 0 C:/cyg

Re: [1.7] bug in chdir

2009-07-15 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 7/15/2009 2:46 AM: >> $ cd //home >> $ # huh? no error reported? > > Sorry Eric, but I can't reproduce this. I tried it on XP and 2K8R2 > with identical result. Weird - it's failing for me on my home network as well,

Re: [1.7] bug in chdir

2009-07-15 Thread Corinna Vinschen
On Jul 15 07:23, Ashok Vadekar wrote: http://cygwin.com/acronyms/#TOFU > - Original Message - > From: [...] http://cygwin.com/acronyms/#PCYMTNQREAIYR > Could it be that a mount point called /home, or //home (if possible), makes a > difference? Not as far as I can see. Creating a //ho

Re: [1.7] bug in chdir

2009-07-15 Thread Ashok Vadekar
Could it be that a mount point called /home, or //home (if possible), makes a difference? - Original Message - From: cygwin-ow...@cygwin.com To: cygwin@cygwin.com Sent: Wed Jul 15 04:46:35 2009 Subject: Re: [1.7] bug in chdir On Jul 14 21:47, Eric Blake wrote: > $ ls //home &

Re: [1.7] bug in chdir

2009-07-15 Thread Corinna Vinschen
On Jul 14 21:47, Eric Blake wrote: > $ ls //home > ls: reading directory //home: No such file or directory > $ # makes sense; I don't have a remote machine named home > $ cd //home > $ # huh? no error reported? > $ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd > //home Sorry Eri

[1.7] bug in chdir

2009-07-14 Thread Eric Blake
$ ls //home ls: reading directory //home: No such file or directory $ # makes sense; I don't have a remote machine named home $ cd //home $ # huh? no error reported? $ /bin/pwd # avoid shortcuts in bash builtin; /bin/pwd uses getcwd //home $ # huh? getcwd is happy with it? $ ls ls: reading director