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

[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    +1-801-349-2682
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

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