directories named '...' (dotdotdot) do not work
Eric Blake
eblake@redhat.com
Wed Feb 2 22:01:00 GMT 2011
[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://cygwin.com/pipermail/cygwin/attachments/20110202/ae544b0c/attachment.sig>
More information about the Cygwin
mailing list