Mail Archives: cygwin/2011/02/02/17:01:41
--------------enig99AEFC5A07E4327D88924FB6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
[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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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?=20=20
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?
--=20
Eric Blake eblake AT redhat DOT com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--------------enig99AEFC5A07E4327D88924FB6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQEcBAEBCAAGBQJNSdQ0AAoJEKeha0olJ0NqzuUIAKS9ghRQqatakmfg+rh2j9pa
D1o+35XgKYPiSn9QpGPAKq+Nmd6QtUWEIW2vW8D37QuIB0lftv2Wvt32V+FpnG3O
Gprt+eJby3N7crey5ENTrZ1XupErYTClPiP6jkXBQVfTqNTAZgFWYzHrXTsXvB2Z
jsQsI8Re6v9bbhxB/UwZMkZlpfu3lJvML6bmnFxbSwYMOizJqK4Je3NRHh/tV0+Z
/8Uv5lMzmpv/ygFIRD8/hA+CkgGegHAOepPLU/ksiaG3OVNgLxuz+6avU42M0OAL
O6qbruV7rbEiY8thJYvBczBSA25yy3kRuHpmqGxS+M0VGDXHecB53mds7acdBlM=
=Pel0
-----END PGP SIGNATURE-----
--------------enig99AEFC5A07E4327D88924FB6--
- Raw text -