Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of tortoisesvn@gmail.com
 designates 209.85.142.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type;
        b=T8tsgiERqV5B6j0TN23rTwpY/r7B1k6N0ZSql+/5GfjE7EdCv1f6911wD4wOchCOJrgIomQZWX3j1xjGRraNxocI/pNUe2DXzSrqhNxszwAhv/sD1Q3UkHPg7GQhW42TTIrBTDCEZNtPu8mPltCjHR3xtM7WkPTjcDMGmR/n46E=
Message-ID: <47A8B735.7040909@gmail.com>
Date: Tue, 05 Feb 2008 20:21:25 +0100
From: =?ISO-8859-1?Q?Stefan_K=FCng?= <tortoisesvn@gmail.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: [patch] creating directories with long names
References: <47921159.9060607@gmail.com>
In-Reply-To: <47921159.9060607@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigE11F584277EF71A19EEE5684"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE11F584277EF71A19EEE5684
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Anyone looked at this yet?
http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/%3cfmvo00$ln=
5$1@ger.gmane.org%3e

Stefan

Stefan K=FCng wrote:
> Hi,
>=20
> While debugging problems with Subversion on Windows (checkouts failed i=
f=20
>  some paths had longer names than around 250 chars), I found a bug in a=
pr:
>=20
> apr transparently converts long pathnames to the Windows specific forma=
t=20
> for long names (it prepends '\\?\'). But that only works properly for=20
> files, because only filenames can be up to MAX_PATH chars long before=20
> the other format is needed. Directories can only be 248 chars long=20
> before the long format is required (see MSDN docs for CreateDirectory:
> http://msdn2.microsoft.com/en-us/library/aa363855(VS.85).aspx).
>=20
> Since the function utf8_to_unicode_path() does the converting for both =

> file and dir paths, it has to use the long format for 248 length string=
s=20
> on, not MAX_PATH. Otherwise, directory creation fails (at least for=20
> paths between 248 chars and 260 chars in length).
>=20
> The attached patch fixes this problem.
>=20
> Stefan
>=20
>=20
> Index: file_io/win32/open.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- file_io/win32/open.c    (revision 613400)
> +++ file_io/win32/open.c    (working copy)
> @@ -55,7 +55,7 @@
>      apr_status_t rv;
>=20
>      /* This is correct, we don't twist the filename if it is will
> -     * definately be shorter than MAX_PATH.  It merits some
> +     * definately be shorter than 248.  It merits some
>       * performance testing to see if this has any effect, but there
>       * seem to be applications that get confused by the resulting
>       * Unicode \\?\ style file names, especially if they use argv[0]
> @@ -65,7 +65,7 @@
>       * Note that a utf-8 name can never result in more wide chars
>       * than the original number of utf-8 narrow chars.
>       */
> -    if (srcremains > MAX_PATH) {
> +    if (srcremains > 248) {
>          if (srcstr[1] =3D=3D ':' && (srcstr[2] =3D=3D '/' || srcstr[2]=
 =3D=3D '\\')) {
>              wcscpy (retstr, L"\\\\?\\");
>              retlen -=3D 4;
>=20


--=20
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net


--------------enigE11F584277EF71A19EEE5684
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.8 (MingW32)

iEYEARECAAYFAkeotzUACgkQNTJADUWeLT4q2wCeJCDQ+UOJNHtT9ruwQaarATRc
BP4AoKu3WY4c00/E8j88vuWqRB3jm6Ee
=qIG1
-----END PGP SIGNATURE-----

--------------enigE11F584277EF71A19EEE5684--