directories named '...' (dotdotdot) do not work

directories named '...' (dotdotdot) do not work

[Ralf Wildenhues]

Hello Cygwin developers,

The following fails for me (and web and list search haven't been helpful):

$ mkdir ...
$ cd ...
$ cp /usr/bin/ls.exe .
$ ./ls.exe
bash: ./ls.exe: No such file or directory

Same with code compiled in this directory.

Is this a bug or by design?

This is from an Automake test failure, where configure failed in such a
directory because the programs produced by a compilation could not be run: 
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7849>.
I would like to know whether we can close the bug as wontfix (and skip the
test  in question on Cygwin) due to system limitations.

Thanks for maintaining Cygwin!
Ralf


--
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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  1 19:37, Ralf Wildenhues wrote:
> Hello Cygwin developers,
> 
> The following fails for me (and web and list search haven't been helpful):
> 
> $ mkdir ...
> $ cd ...
> $ cp /usr/bin/ls.exe .
> $ ./ls.exe
> bash: ./ls.exe: No such file or directory
> 
> Same with code compiled in this directory.
> 
> Is this a bug or by design?

Works fine for me:

  $ uname -a
  CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
  $ cd tmp
  $ mkdir ...
  $ cd ...
  $ cp /usr/bin/ls.exe .
  $ ./ls
  ls.exe

I tried on NTFS, Samba and NFS.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[marco atzeri]

On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen  wrote:
> On Feb  1 19:37, Ralf Wildenhues wrote:
>> Hello Cygwin developers,
>>
>> The following fails for me (and web and list search haven't been helpful):
>>
>> $ mkdir ...
>> $ cd ...
>> $ cp /usr/bin/ls.exe .
>> $ ./ls.exe
>> bash: ./ls.exe: No such file or directory
>>
>> Same with code compiled in this directory.
>>
>> Is this a bug or by design?
>
> Works fine for me:
>
>  $ uname -a
>  CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
>  $ cd tmp
>  $ mkdir ...
>  $ cd ...
>  $ cp /usr/bin/ls.exe .
>  $ ./ls
>  ls.exe
>
> I tried on NTFS, Samba and NFS.
>
>
> Corinna
>

not working also here:

$ uname -a
CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin

$ ./ls.exe
bash: ./ls.exe: No such file or directory

$ ./ls
bash: ./ls: No such file or directory

$ ls -l
total 128
-rwxr-xr-x+ 1 Marco Administrators 129550 Feb  2 20:55 ls.exe


Marco

--
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: directories named '...' (dotdotdot) do not work

[Lee Rothstein]

On 2/2/2011 3:51 PM, marco atzeri wrote:

 > On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen  wrote:

 >> On Feb  1 19:37, Ralf Wildenhues wrote:

 >>> The following fails for me (and web and list search haven't been 
helpful):

 >>> $ mkdir ...
 >>> $ cd ...
 >>> $ cp /usr/bin/ls.exe .
 >>> $ ./ls.exe
 >>> bash: ./ls.exe: No such file or directory

 >>> Same with code compiled in this directory.

 >>> Is this a bug or by design?

 >> Works fine for me:

 >>  $ uname -a
 >>  CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
 >>  $ cd tmp
 >>  $ mkdir ...
 >>  $ cd ...
 >>  $ cp /usr/bin/ls.exe .
 >>  $ ./ls
 >>  ls.exe

 >> I tried on NTFS, Samba and NFS.

 >> Corinna

 > not working also here:

 > $ uname -a
 > CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin

 > $ ./ls.exe
 > bash: ./ls.exe: No such file or directory

 > $ ./ls
 > bash: ./ls: No such file or directory

 > $ ls -l
 > total 128
 > -rwxr-xr-x+ 1 Marco Administrators 129550 Feb  2 20:55 ls.exe

Works for me on NTFS.

     $ uname -a
     CYGWIN_NT-6.0-WOW64 GW2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin

Conceivably, this could be a bug that might be important, but I
have to ask:

     How good an idea is it to name a directory '...'?

Let me take a crack at an answer:

     About as good an idea as embedding spaces in PATH names!
     I.e, don't do it unless Mr. Bill holds a gun to your head!

Lee

--
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: directories named '...' (dotdotdot) do not work

[Andrew DeFaria]

On 02/02/2011 04:13 PM, Lee Rothstein wrote:
> On 2/2/2011 3:51 PM, marco atzeri wrote:
>
> > On Wed, Feb 2, 2011 at 9:45 PM, Corinna Vinschen  wrote:
>
> >> On Feb  1 19:37, Ralf Wildenhues wrote:
>
> >>> The following fails for me (and web and list search haven't been 
> helpful):
>
> >>> $ mkdir ...
> >>> $ cd ...
> >>> $ cp /usr/bin/ls.exe .
> >>> $ ./ls.exe
> >>> bash: ./ls.exe: No such file or directory
>
> >>> Same with code compiled in this directory.
>
> >>> Is this a bug or by design?
>
> >> Works fine for me:
>
> >>  $ uname -a
> >>  CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> >>  $ cd tmp
> >>  $ mkdir ...
> >>  $ cd ...
> >>  $ cp /usr/bin/ls.exe .
> >>  $ ./ls
> >>  ls.exe
>
> >> I tried on NTFS, Samba and NFS.
>
> >> Corinna
>
> > not working also here:
>
> > $ uname -a
> > CYGWIN_NT-5.1 1.7.8s(0.235/5/3) 20110130 23:04:08 i686 Cygwin
>
> > $ ./ls.exe
> > bash: ./ls.exe: No such file or directory
>
> > $ ./ls
> > bash: ./ls: No such file or directory
>
> > $ ls -l
> > total 128
> > -rwxr-xr-x+ 1 Marco Administrators 129550 Feb  2 20:55 ls.exe
>
> Works for me on NTFS.
>
>     $ uname -a
>     CYGWIN_NT-6.0-WOW64 GW2 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
>
> Conceivably, this could be a bug that might be important, but I
> have to ask:
>
>     How good an idea is it to name a directory '...'?
It's a supported directory name in that it is allowed. As such, if not 
working, it a bug. This is regardless if it's a good idea or not.
-- 
Andrew DeFaria <http://defaria.com>
Is it my imagination, or do buffalo wings taste like chicken?


--
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: directories named '...' (dotdotdot) do not work

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

On 02/02/2011 01:45 PM, Corinna Vinschen wrote:
> Works fine for me:
> 
>   $ uname -a
>   CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
>   $ cd tmp
>   $ mkdir ...
>   $ cd ...
>   $ cp /usr/bin/ls.exe .
>   $ ./ls
>   ls.exe
> 
> I tried on NTFS, Samba and NFS.

Difference in Windows version?

$ uname -a
CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
$ pwd
/tmp/...
$ ls
ls.exe
$ ./ls
bash: ./ls: No such file or directory

or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 13:56, Eric Blake wrote:
> On 02/02/2011 01:45 PM, Corinna Vinschen wrote:
> > Works fine for me:
> > 
> >   $ uname -a
> >   CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> >   $ cd tmp
> >   $ mkdir ...
> >   $ cd ...
> >   $ cp /usr/bin/ls.exe .
> >   $ ./ls
> >   ls.exe
> > 
> > I tried on NTFS, Samba and NFS.
> 
> Difference in Windows version?
> 
> $ uname -a
> CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> $ pwd
> /tmp/...
> $ ls
> ls.exe
> $ ./ls
> bash: ./ls: No such file or directory
> 
> or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)?

No, I'm using tcsh.  Apparently you're right, it doesn't work in
XP, but it works in W7.  Looks like Microsoft reworked the CreateProcess
call at some point.  I have an idea how this might be possible to
workaround.  Stay tuned.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 22:28, Corinna Vinschen wrote:
> On Feb  2 13:56, Eric Blake wrote:
> > On 02/02/2011 01:45 PM, Corinna Vinschen wrote:
> > > Works fine for me:
> > > 
> > >   $ uname -a
> > >   CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> > >   $ cd tmp
> > >   $ mkdir ...
> > >   $ cd ...
> > >   $ cp /usr/bin/ls.exe .
> > >   $ ./ls
> > >   ls.exe
> > > 
> > > I tried on NTFS, Samba and NFS.
> > 
> > Difference in Windows version?
> > 
> > $ uname -a
> > CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> > $ pwd
> > /tmp/...
> > $ ls
> > ls.exe
> > $ ./ls
> > bash: ./ls: No such file or directory
> > 
> > or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)?
> 
> No, I'm using tcsh.  Apparently you're right, it doesn't work in
> XP, but it works in W7.  Looks like Microsoft reworked the CreateProcess
> call at some point.  I have an idea how this might be possible to
> workaround.  Stay tuned.

Btw., the "..." directory is not recognized at all by cmd.exe.  If you
try to cd into it, it's simply ignored.  If you set the CWD to it
and start cmd, cmd thinks it is in the parent directory.  This occurs
on XP *and* W7.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Christian Franke]

Corinna Vinschen wrote:
>
> Btw., the "..." directory is not recognized at all by cmd.exe.  If you
> try to cd into it, it's simply ignored.  If you set the CWD to it
> and start cmd, cmd thinks it is in the parent directory.  This occurs
> on XP *and* W7.
>
>    

At least on XP cmd and others could not be run from a subdir below "...":

$ /bin/pwd
/tmp/...

$ cmd.exe /c cd
C:\cygwin\tmp

$ mkdir x

$ cd x

# /bin/pwd
/tmp/.../x

# cmd.exe /c cd
-bash: /cygdrive/c/WINDOWS/system32/cmd.exe: Not a directory


Same for "....", ".....", ....

Different path checking in win32api layer and ntdll layer ?

I would suggest to either quote or reject "..." in Cygwin.

Christian


--
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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 22:55, Christian Franke wrote:
> Corinna Vinschen wrote:
> >
> >Btw., the "..." directory is not recognized at all by cmd.exe.  If you
> >try to cd into it, it's simply ignored.  If you set the CWD to it
> >and start cmd, cmd thinks it is in the parent directory.  This occurs
> >on XP *and* W7.
> >
> 
> At least on XP cmd and others could not be run from a subdir below "...":
> 
> $ /bin/pwd
> /tmp/...
> 
> $ cmd.exe /c cd
> C:\cygwin\tmp
> 
> $ mkdir x
> 
> $ cd x
> 
> # /bin/pwd
> /tmp/.../x
> 
> # cmd.exe /c cd
> -bash: /cygdrive/c/WINDOWS/system32/cmd.exe: Not a directory
> 
> 
> Same for "....", ".....", ....
> 
> Different path checking in win32api layer and ntdll layer ?

Yes, definitely.  I explained that in
http://cygwin.com/ml/cygwin/2011-02/msg00078.html

On the Win32 level the path is massaged so that it follows DOS filename
conventions.  This is not done on the native NT level.  The long-path
prefix when used on the Win32 level (but only in the UNICODE API) disables
the DOSifying and just passes the path through to the native NT API.

> I would suggest to either quote or reject "..." in Cygwin.

Given that the path works fine except for starting an executable, and
given that starting an app works fine in Vista and later, there's no
reason to disallow the "..." path component entirely.  I'm not giving in
to the old DOS path conventions, unless there's absolutely no way around
it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 22:28, Corinna Vinschen wrote:
> On Feb  2 13:56, Eric Blake wrote:
> > On 02/02/2011 01:45 PM, Corinna Vinschen wrote:
> > > Works fine for me:
> > > 
> > >   $ uname -a
> > >   CYGWIN_NT-6.1 vmbert7 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> > >   $ cd tmp
> > >   $ mkdir ...
> > >   $ cd ...
> > >   $ cp /usr/bin/ls.exe .
> > >   $ ./ls
> > >   ls.exe
> > > 
> > > I tried on NTFS, Samba and NFS.
> > 
> > Difference in Windows version?
> > 
> > $ uname -a
> > CYGWIN_NT-5.1 LOUNGE 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> > $ pwd
> > /tmp/...
> > $ ls
> > ls.exe
> > $ ./ls
> > bash: ./ls: No such file or directory
> > 
> > or maybe in bash versions (since I did just upgrade bash from 3.2 to 4.1)?
> 
> No, I'm using tcsh.  Apparently you're right, it doesn't work in
> XP, but it works in W7.  Looks like Microsoft reworked the CreateProcess
> call at some point.  I have an idea how this might be possible to
> workaround.  Stay tuned.

Yes, my workaround works.  What happens is that XP's CreateProcess calls
an internal function at one point which drops leading spaces and
trailing dots and spaces from the path, since these were always invalid
in DOS paths.  And a path component which consists entirely of dots
and/or spaces is just invisible from a DOS path perspective.

However, if the path to the executable is prepended by the long-path
prefix "\\?\", then the CreateProcess function understands the path
even on XP since the prefix suppresses the DOS path strangling.

However, that's not a generic solution.  At one point we deliberately
dropped the preceeding "\\?\" because this breaks some native Win32
child processes which are not long-path aware.  So, right now, we only
keep the long-path prefix if the path is actually longer than MAX_PATH.

To fix that, we would have to scan the entire path for path components
which contain leading spaces or trailing dots or spaces.  That makes
fork even slower than it already is.

Given that it works fine on Vista and Windows 7 anyway, is it really
worth to add this extra code just to support an old OS in a very rare
situation?  


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

[re-adding Ralf, in case he's not subscribed]

On 02/02/2011 02:53 PM, Corinna Vinschen wrote:
>> No, I'm using tcsh.  Apparently you're right, it doesn't work in
>> XP, but it works in W7.  Looks like Microsoft reworked the CreateProcess
>> call at some point.  I have an idea how this might be possible to
>> workaround.  Stay tuned.
> 
> Yes, my workaround works.  What happens is that XP's CreateProcess calls
> an internal function at one point which drops leading spaces and
> trailing dots and spaces from the path, since these were always invalid
> in DOS paths.  And a path component which consists entirely of dots
> and/or spaces is just invisible from a DOS path perspective.
> 
> However, if the path to the executable is prepended by the long-path
> prefix "\\?\", then the CreateProcess function understands the path
> even on XP since the prefix suppresses the DOS path strangling.
> 
> However, that's not a generic solution.  At one point we deliberately
> dropped the preceeding "\\?\" because this breaks some native Win32
> child processes which are not long-path aware.  So, right now, we only
> keep the long-path prefix if the path is actually longer than MAX_PATH.
> 
> To fix that, we would have to scan the entire path for path components
> which contain leading spaces or trailing dots or spaces.  That makes
> fork even slower than it already is.

Well, that would only be if the path is shorter than MAX_PATH (256)
bytes, so it's not like we have a quadratic scaling problem over
thousands of bytes.  Furthermore, using a directory literally named
'...' already causes problems for windows programs that ar not long-path
aware, so the workaround is no worse than what they currently get from
such a path.  But you're right, that taking the time to scan for any
occurrence of:

'.\', './', '/.', ' \', ' /'

and checking for five patterns across 256 bytes definitely adds time.

> Given that it works fine on Vista and Windows 7 anyway, is it really
> worth to add this extra code just to support an old OS in a very rare
> situation?  

Can't we make the scan conditional on the windows version?  That is,
spend the extra time to keep XP happy, but skip the scan on newer Windows?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 15:01, Eric Blake wrote:
> [re-adding Ralf, in case he's not subscribed]
> 
> On 02/02/2011 02:53 PM, Corinna Vinschen wrote:
> >> No, I'm using tcsh.  Apparently you're right, it doesn't work in
> >> XP, but it works in W7.  Looks like Microsoft reworked the CreateProcess
> >> call at some point.  I have an idea how this might be possible to
> >> workaround.  Stay tuned.
> > 
> > Yes, my workaround works.  What happens is that XP's CreateProcess calls
> > an internal function at one point which drops leading spaces and
> > trailing dots and spaces from the path, since these were always invalid
> > in DOS paths.  And a path component which consists entirely of dots
> > and/or spaces is just invisible from a DOS path perspective.
> > 
> > However, if the path to the executable is prepended by the long-path
> > prefix "\\?\", then the CreateProcess function understands the path
> > even on XP since the prefix suppresses the DOS path strangling.
> > 
> > However, that's not a generic solution.  At one point we deliberately
> > dropped the preceeding "\\?\" because this breaks some native Win32
> > child processes which are not long-path aware.  So, right now, we only
> > keep the long-path prefix if the path is actually longer than MAX_PATH.
> > 
> > To fix that, we would have to scan the entire path for path components
> > which contain leading spaces or trailing dots or spaces.  That makes
> > fork even slower than it already is.
> 
> Well, that would only be if the path is shorter than MAX_PATH (256)
> bytes, so it's not like we have a quadratic scaling problem over
> thousands of bytes.  Furthermore, using a directory literally named
> '...' already causes problems for windows programs that ar not long-path
> aware, so the workaround is no worse than what they currently get from
> such a path.  But you're right, that taking the time to scan for any
> occurrence of:
> 
> '.\', './', '/.', ' \', ' /'
> 
> and checking for five patterns across 256 bytes definitely adds time.
> 
> > Given that it works fine on Vista and Windows 7 anyway, is it really
> > worth to add this extra code just to support an old OS in a very rare
> > situation?  
> 
> Can't we make the scan conditional on the windows version?  That is,
> spend the extra time to keep XP happy, but skip the scan on newer Windows?

I'm not opposed to a pre-Vista workaround.  The code should be added to
the "if (runpath)" code starting at line 494 in spawn.cc.  If you have
an idea how to do this test as fast as possible, please send a patch.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  2 23:11, Corinna Vinschen wrote:
> On Feb  2 15:01, Eric Blake wrote:
> > On 02/02/2011 02:53 PM, Corinna Vinschen wrote:
> > > [...]
> > > To fix that, we would have to scan the entire path for path components
> > > which contain leading spaces or trailing dots or spaces.  That makes
> > > fork even slower than it already is.
> > 
> > Well, that would only be if the path is shorter than MAX_PATH (256)
> > bytes, so it's not like we have a quadratic scaling problem over
> > thousands of bytes.  Furthermore, using a directory literally named
> > '...' already causes problems for windows programs that ar not long-path
> > aware, so the workaround is no worse than what they currently get from
> > such a path.  But you're right, that taking the time to scan for any
> > occurrence of:
> > 
> > '.\', './', '/.', ' \', ' /'
> > 
> > and checking for five patterns across 256 bytes definitely adds time.
> > 
> > > Given that it works fine on Vista and Windows 7 anyway, is it really
> > > worth to add this extra code just to support an old OS in a very rare
> > > situation?  
> > 
> > Can't we make the scan conditional on the windows version?  That is,
> > spend the extra time to keep XP happy, but skip the scan on newer Windows?
> 
> I'm not opposed to a pre-Vista workaround.  The code should be added to
> the "if (runpath)" code starting at line 494 in spawn.cc.  If you have
> an idea how to do this test as fast as possible, please send a patch.

Oh, btw., only three patterns.  At this point in the code the slashes
are already converted to backslashes.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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: directories named '...' (dotdotdot) do not work

[Ralf Wildenhues]

Hello, and thanks for investigating this,

> On 02/02/2011 02:53 PM, Corinna Vinschen wrote:
> > Given that it works fine on Vista and Windows 7 anyway, is it really
> > worth to add this extra code just to support an old OS in a very rare
> > situation?  

FWIW, not for me.  I was merely trying to be a good netizen by reporting
bugs that I encounter.

Thanks,
Ralf



--
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: directories named '...' (dotdotdot) do not work

[Corinna Vinschen]

On Feb  3 06:38, Ralf Wildenhues wrote:
> Hello, and thanks for investigating this,
> 
> > On 02/02/2011 02:53 PM, Corinna Vinschen wrote:
> > > Given that it works fine on Vista and Windows 7 anyway, is it really
> > > worth to add this extra code just to support an old OS in a very rare
> > > situation?  
> 
> FWIW, not for me.  I was merely trying to be a good netizen by reporting
> bugs that I encounter.

Much appreciated.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          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