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


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


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