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 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  If you have
an idea how to do this test as fast as possible, please send a patch.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

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